• PTP 时钟


    Basic

    SyncE Principle mechanism

    SyncE is only  frequency synchronization, while SyncE and PTP are time synchronization together.

    PTP Principle mechanism

    There are 2 ptp delay-mechanism e2e p2p }

    By default, different protocol standards correspond to different delay measurement mechanisms.

    The defaults of different PTP protocol standards are different:

    • When the PTP protocol standard is IEEE 1588 version 2 and SMPTE ST 2059-2, the default delay measurement mechanism is the request-response mechanism.
    • When the PTP protocol standard is IEEE 802.1AS, the default delay measurement mechanism is the end delay mechanism

    Offset = (t2 – t1) – [(t2 – t1) + (t4 – t3)] / 2 = [(t2 – t1) – (t4 – t3) ] / 2

    We can show offset in ptp4l log

    Offset is positive(+), indicating that the local clock is faster than the master clock.

    Offset is negative(-), indicating that the local clock is slower than the master clock.

    Dump PTP package

    PTP-P2P-Capture.pcap

    Example:

    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-configuring_ptp_using_ptp4l#sec-Using_the_PTP_Management_Client

    GET
    pmc -u -b 0 'GET PORT_DATA_SET'
    pmc -u -b 0 -d 0 'GET TIME_STATUS_NP'

    All get command

    GET
    hops=${hops:-0}
    dom=${dom:-0}
     
    pmc -u -b $hops -d $dom 'GET ANNOUNCE_RECEIPT_TIMEOUT'
    pmc -u -b $hops -d $dom 'GET CLOCK_ACCURACY'
    pmc -u -b $hops -d $dom 'GET CLOCK_DESCRIPTION'
    pmc -u -b $hops -d $dom 'GET CURRENT_DATA_SET'
    pmc -u -b $hops -d $dom 'GET DEFAULT_DATA_SET'
    pmc -u -b $hops -d $dom 'GET DELAY_MECHANISM'
    pmc -u -b $hops -d $dom 'GET DOMAIN'
    pmc -u -b $hops -d $dom 'GET GRANDMASTER_SETTINGS_NP'
    pmc -u -b $hops -d $dom 'GET LOG_ANNOUNCE_INTERVAL'
    pmc -u -b $hops -d $dom 'GET LOG_MIN_PDELAY_REQ_INTERVAL'
    pmc -u -b $hops -d $dom 'GET LOG_SYNC_INTERVAL'
    pmc -u -b $hops -d $dom 'GET NULL_MANAGEMENT'
    pmc -u -b $hops -d $dom 'GET PARENT_DATA_SET'
    pmc -u -b $hops -d $dom 'GET PORT_DATA_SET'
    pmc -u -b $hops -d $dom 'GET PORT_DATA_SET_NP'
    pmc -u -b $hops -d $dom 'GET PRIORITY1'
    pmc -u -b $hops -d $dom 'GET PRIORITY2'
    pmc -u -b $hops -d $dom 'GET SLAVE_ONLY'
    pmc -u -b $hops -d $dom 'GET TIMESCALE_PROPERTIES'
    pmc -u -b $hops -d $dom 'GET TIME_PROPERTIES_DATA_SET'
    pmc -u -b $hops -d $dom 'GET TIME_STATUS_NP'
    pmc -u -b $hops -d $dom 'GET TRACEABILITY_PROPERTIES'
    pmc -u -b $hops -d $dom 'GET USER_DESCRIPTION'
    pmc -u -b $hops -d $dom 'GET VERSION_NUMBER'


    When PTP time synchronization is working properly, new messages with offsets and frequency adjustments will be printed periodically to the ptp4l and phc2sys 

    (if hardware time stamping is used) outputs. These values will eventually converge after a short period of time. These messages can be seen in /var/log/messages file

    LOG
    tail -f /var/log/messages grep ptp4l

    check sys clock

    SYS CLOCK
    cat /sys/devices/system/clocksource/clocksource0/available_clocksource
    cat /sys/devices/system/clocksource/clocksource0/current_clocksource
    # echo 'tsc' > /sys/devices/system/clocksource/clocksource0/current_clocksource
    cat /proc/timer_list

    check PTP clock name 

    PTP Clock Name
    # cat /sys/class/ptp/ptp*/clock_name
    tg3 clock
    i40e
    ice-0000:31:00
    tg3 clock
    i40e
    i40e
    i40e
    i40e
    i40e
     
    # cat /sys/class/ptp/ptp10/clock_name
    i40e

    1588 Profile Configuration Validation

    More details ref  4.71588 Profile Configuration Validation Tool for ptp4l

    There are several configuration file for the G.8265.1, G.8275.1, or G.8275.2 profiles, ref: https://www2.renesas.cn/us/en/document/whp/linux-phc-infrastructure-5g

    PTP profiles
    # ps -ef |grep ptp
    root     105083      1  0 Jan14 ?        00:00:09 tmux new-session -s ptp1588 -n PTP -d
    root     105161 105092  0 Jan14 pts/3    00:00:15 ptp4l -i p1p4 -m -f /root/default_slave.cfg
     
    # cat /root/default_slave.cfg
    [global]
    dataset_comparison              G.8275.x
    G.8275.defaultDS.localPriority  255
    logAnnounceInterval             3
    masterOnly                      0
    G.8275.portDS.localPriority     255
    hybrid_e2e                      1
    inhibit_multicast_service       1
    unicast_listen                  1
    unicast_req_duration            32
    #
    # Customize the following for slave operation:
    #
    [unicast_master_table]
    table_id                        1
    logQueryInterval                3
    UDPv4                           192.168.1.149
    #
    [p1p4]
    unicast_master_table            1

    PI servo

    The proportional integral servo system is integrated for ptp4l, which can resist interference. Parameters need to be adjusted:

    Precision Time Protocol on Linux ~ Introduction to linuxptp 

    PI servo for Linux ptp4l

    Synchronizing the System Clock

    check phc clock bigger than 1000

    PHC offset
    LEN=4 # 4 means 1000, 3 means 100
    grep -E "phc offset\s+[0-9]{$LEN,}" /var/log/messages

    check phc clock rms than 100

    PHC RMS
    LEN=3 # 4 means 1000, 3 means 100
    grep -E "phc2sys.*rms\s+[0-9]{$LEN,}" /var/log/messages

    hc2sys reports the time offset between PHC and System Clock, which determines if the clocks are synchronized.

    phc2sys[5374168.545]: CLOCK_REALTIME phc offset   -372582 s0 freq    +246 delay   6649
    phc2sys[5374169.545]: CLOCK_REALTIME phc offset   -372832 s1 freq      -4 delay   6673
    phc2sys[5374170.547]: CLOCK_REALTIME phc offset        68 s2 freq     +64 delay   6640
    phc2sys[5374171.547]: CLOCK_REALTIME phc offset       -20 s2 freq      -3 delay   6687
    phc2sys[5374172.547]: CLOCK_REALTIME phc offset        47 s2 freq     +58 delay   6619
    phc2sys[5374173.548]: CLOCK_REALTIME phc offset       -40 s2 freq     -15 delay   6680
    

    The offset information reported by phc2sys shows the time offset between the PHC and the System clock. If phc2sys consistently reports offset lower than 100 ns, the System clock is synchronized.

    check phc clock max than 100

    PHC MAX
    LEN=4 # 3 means 1000, 3 means 100
    grep -E "phc2sys.*max\s+[0-9]{$LEN,}" /var/log/messages

    check ptp clock bigger than 1000

    PTP OFFSET
    LEN=4 # 4 means 1000, 3 means 100
    grep -E "master offset\s+[0-9]{$LEN,}" /var/log/messages

    check ptp clock max bigger than 100

    PTP RMS
    LEN=3 # 4 means 1000, 3 means 100
    grep -E "ptp4l.*rms\s+[0-9]{$LEN,}" /var/log/messages

    The output for ptp4l is:

    ptp4l[5374018.735]: rms  787 max 1208 freq -38601 +/- 1071 delay  -14 +/-   0
    ptp4l[5374019.735]: rms 1314 max 1380 freq -36204 +/- 346 delay   -14 +/-   0
    ptp4l[5374020.735]: rms  836 max 1106 freq -35734 +/-  31 delay   -14 +/-   0
    ptp4l[5374021.736]: rms  273 max  450 freq -35984 +/-  97 delay   -14 +/-   0
    ptp4l[5374022.736]: rms   50 max   82 freq -36271 +/-  64 delay   -14 +/-   0
    ptp4l[5374023.736]: rms   81 max   86 freq -36413 +/-  17 delay   -14 +/-   0

    The rms value reported by ptp4l once the slave has locked with the GM shows the root mean square of the time offset between the PHC and the GM clock.
    If ptp4l consistently reports rms lower than 100 ns, the PHC is synchronized

    check ptp clock rms bigger than 100

    PTP MAX
    LEN=3 # 4 means 1000, 3 means 100
    grep -E "ptp4l.*max\s+[0-9]{$LEN,}" /var/log/messages

    What is with al of these TLVs in the Precision Time Protocol?

    Let’s start at the beginning, TLV stands for “type, length, value.” It is a general means to extend a PTP message with some extra information for some optional feature or whatever. TLVs are used in many network protocols, not just PTP. A TLV in PTP has the structure:

    Troubleshooting

    REF:https://tsn.readthedocs.io/timesync.html#troubleshooting

    In this section we discuss some issues that we have faced when trying to synchronize time using Linux PTP in different systems

    System time isn’t synchronized with PHC

    If PHC offset never goes below hundreds (of nanoseconds)- or if it suddenly spikes (as seen on phc2sys log) - leaving system time out of sync, this section provides some hints on what to do.

    Confirm NTP is not running

    An NTP service may be running and changing the system clock. On systems with systemd, run:

    Check NTP
    timedatectl | grep NTP
    If the output shows NTP service: active, disable it:
    Disable NTP
    timedatectl set-ntp false

    Check if NTP has been disabled and run the clock synchronization steps again and verify that the clocks are in sync.

    Check NetworkManager is not messing with the NIC

    When NetworkManager is running, it may reset the NIC after the qdisc setup. In this situation, PHC and the system clock may be out of sync. Do not allow the NetworkManager to manage the TSN capable NIC. Add the following to the /etc/NetworkManager/NetworkManager.conf file:

    Network Configure
    [main]
    plugins=keyfile
     
    [keyfile]
    unmanaged-devices=interface-name:eth0
    Restart NetworkManager. Run the clock synchronization steps again and verify the clocks are in sync.

    Ensure qdisc setup is done before clock synchronization

    Qdisc setup resets the NIC, and that can make ptp4l out of sync. If any qdisc setup needs to be done after clocks are already in sync, repeat clock synchronization steps again and verify that the clocks are still in sync.

    Confirm only one instance of ptp4l or phc2sys is running

    Multiple instances of ptp4l or phc2sys adjusting a single clocksource or sending out Sync messages can put the clocks out of sync. So, ensure only a single instance (per network interface) of both the daemons is running at a time. pgrep can be useful to ensure only one instance of a particular process is running. Look at pgrep(1) manpage for more details.

    UTC offset change when loosing grand master

    phc2sys: don't synchronize clock to itself.

    avtp

    https://gstreamer.freedesktop.org/documentation/avtp/index.html?gi-language=c#audio-video-transport-protocol-avtp-plugin

    Audio Video Transport Protocol (AVTP) Plugin

    The AVTP plugin implements typical Talker and Listener functionalities that can be leveraged by GStreamer-based applications in order to implement TSN audio/video applications.

    REF:

    Source code and discussion in Mail list

  • 相关阅读:
    设计模式 学习笔记(8) 适配器模式、单例模式、享元模式
    设计模式 学习笔记(7) 抽象工厂模式、状态模式
    判断页面是否被嵌入iframe里面
    css3的transform:tanslateZ没有效果
    vuecli3多页应用配置与优化
    正则的test和exec方法与字符串的search,replace,match,split方法的使用
    实验 1:Mininet 源码安装和可视化拓扑工具
    2020软件工程第一次作业
    R12新功能
    FSG(1) FSG报表组件
  • 原文地址:https://www.cnblogs.com/shaohef/p/15808900.html
Copyright © 2020-2023  润新知