Hi Dennis. Thanks for all that information. I had a look at the reference manual for uBlox f9p (my GNSS receiver) and it has a message (UBX-NAV-TIMELS) which contains detailed information of when/if the next leap second will be added to UTC, so it would be possible for my GM to dynamically update that information by parsing that GNSS packet, but I think for simplicity it is OK to just use 37 sec's since we care about the UTC time. I might have a problem if the system is running during leap second insertion, and it depends on how ntpd handles it which I will dig deeper into (seems like chronyd is a better implementation). Assuming worst case, which is that the system clock is stepped 1 second the phc2sys utility will sync up the PTP clock after this event and the PTP slaves will also eventually be synced. This is not ideal for a robotics system especially since we are using it to distribute time to different sensors that timestamps their packets. In the period around a leap second insertion we will have some frequency offset and it could affect algorithms which are integrating up measurements from accelerometers or gyroscopes.
After reading your email and checking out more sources I know believe that using TAI is better suited for these real time robotics systems where we are mostly interested in accurate relative time. I am still interested in knowing whether running pmc 'SET GRANDMASTER_SETTINGS_NP' at boot is the right way to go for setting the utcOffsetValid flag. Alternatively I could instruct pmc to use utcOffset=0, in which case the utcOffsetValid flag doesnt have to be set. Thanks, Erling ________________________________ Fra: Dennis Hagarty (dehagart) <dehag...@cisco.com> Sendt: tirsdag 15. juni 2021 20:31:03 Til: Erling Rennemo Jellum; linuxptp-users@lists.sourceforge.net Emne: RE: Where does ptp4l get the currentOffsetValid flag from? Hi, I might not be able to answer the first question clearly, but I can help with the second. Firstly, the UTC offset is sent from the GM to the slave device in the Announce message, along with the offset valid flag. So, the onus is on the GM to determine what the offset is and correctly distribute it. The basis for all knowledge on the leap second is the International Earth Rotation and Reference Systems (IERS) organization in Paris, and they make that determination every six months. The decision is distributed via their “Bulletin C” every Jan/July which is kept here: https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt There are several mechanisms whereby that information can be learned and distributed. The specific approach depends on the timing transport, either GPS/GNSS, or whatever (too long to replicate here). There is several versions of leap seconds files that allow reference to the latest picture. See one at: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list PTP also uses a mechanism to distribute the leap second information and timing (part of the mechanism is this offset and the valid flag). The GM announces to the slaves when the leap second is coming (12 hours before) and the slaves then update the offset at that time to the new value. Any leap events are scheduled for the second following 23:59:59 UTC at 2 possible dates: 30 June or 31 Dec. So, the short answer is that there needs to be a mechanism to get that information from the reference source into the brain of the PTP GM. It can be configuration, some automated process or whatever. If I understand your case, the PTP is taking its reference from the system clock – and that comes from NTP. So there needs to be multiple conversions, since the system clock is approximating UTC. PTP normally uses TAI timestamps so the offset comes into play there in the updating of the PTP hardware clock on the GM end from the UTC system clock. Then at the other end, the offset would be necessary to take any conversion from TAI back to UTC (again with the phc2sys process) If your application at the other end uses UTC from the system clock, then the TAI->UTC conversion needs to be accurate on the slave (and master) end or you’ll have the wrong UTC. Normally, on the slave end, my understanding is that recent versions of phc2sys uses the information from the announce message to do that conversion (using those fields/flags you mentioned). I’m not really sure how it’s supposed to happen on the GM side, I’d imagine there is a similar process using the configuration of the offset from the PTP config file. I have no idea how the leap second mechanism works on the GM end for ptp4l. Of course, as long as the UTC offset is the same at both ends (even zero), it shouldn’t matter as long as the conversion is symmetrical, but of course, the TAI time will be incorrect in that case. Hope that helps Dennis Please check out my new book “Synchronizing 5G Mobile Networks” from Cisco Press: https://www.ciscopress.com/store/synchronizing-5g-mobile-networks-9780136836254 Synchronizing 5G Mobile Networks | Cisco Press<https://www.ciscopress.com/store/synchronizing-5g-mobile-networks-9780136836254> www.ciscopress.com Failure to properly design, implement, and manage it can dramatically reduce mobile network efficiency, reliability and capacity. In 5G environments, time synchronization is even more important to mobile network service providers, and its also increasingly important to a wide array of emerging applications, from finance to IoT to media. From: Erling Rennemo Jellum <erling.r.jel...@ntnu.no> Sent: Tuesday, 15 June 2021 18:22 To: linuxptp-users@lists.sourceforge.net Subject: [Linuxptp-users] Where does ptp4l get the currentOffsetValid flag from? Hi and thanks for a great open-source project. I am trying to setup a grandmaster based on a BeagleBone Black which synchronizes its system clock to a uBlox F9P GNSS receiver through ntpd. I am using phc2sys to synchronize the PTP clock to the system clock. It mostly works great except that it announces "currentUtcOffsetValid:0" even though an offset is applied to the UTC time,. At the bottom of the email I have added the ptp4l config file and the phc2sys service file. If I understand it correctly phc2sys is waiting for ptp4l to start and then applies the utcOffset desired by ptp4l to the system clock when synchronizing. I can verify the currentUtcOffsetValid:0 on both slave and gm side: erling@ubuntu-ntnu ~> sudo pmc -u -b 0 'GET TIME_PROPERTIES_DATA_SET' sending: GET TIME_PROPERTIES_DATA_SET a4bb6d.fffe.b27ab3-0 seq 0 RESPONSE MANAGEMENT TIME_PROPERTIES_DATA_SET currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 0 ptpTimescale 1 timeTraceable 0 frequencyTraceable 0 timeSource 0xa0 and at the grandmaster side: debian@beaglebone:~$ sudo pmc -u -b 0 'GET GRANDMASTER_SETTINGS_NP' sending: GET GRANDMASTER_SETTINGS_NP 78a504.fffe.caf7d4-0 seq 0 RESPONSE MANAGEMENT GRANDMASTER_SETTINGS_NP clockClass 128 clockAccuracy 0xfe offsetScaledLogVariance 0xffff currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 0 ptpTimescale 1 timeTraceable 0 frequencyTraceable 0 timeSource 0x20 I have taken a look at the source code but it seemed like the currentUtcOffsetValid only was modified through the pmc utility. I have verified that I can in fact manually set the currentUtcOffset by using pmc 'SET GRANDMASTER_SETTINGS_NP', this would have to be done at each boot. My question for you is twofold 1. Is there another perferred way of getting the grandmaster to announce currentUtcOffsetVaid: 1? 2. As far as I understand the UTC-TAI offset is changing so by hardcoding an offset (which I have done) in the ptp4l config will at some point in the future make it outdated (wrt TAI) A) Is there a way to have phc2sys and ptp4l update the utcOffset in the future when a new leap second is added? B) What are the practical consequences of having an outdated UtcOffset? We are using it in a robotics system and timestamp events in UTC. I would assume that in this case I could use an arbitrary UtcOffset as long as it is announced and currentUtcOffsetValid:1 I have a feeling that I am failing to understand something fundamental about how these tools work and I gladly take pointers are links to documents/blogs/etc describing it. Thanks for your time, Erling R. Jellum -------------------------------------- ### phc2sys service file: ### debian@beaglebone:~$ cat /lib/systemd/system/phc2sys.service [Unit] Description=Synchronize system clock or PTP hardware clock (PHC) Documentation=man:phc2sys # I have added ntp.service here to try to make sure that the system clock is synced to GPS before phc2sys runs After=ntp.service After=ntpdate.service Requires=ptp4l.service After=ptp4l.service [Service] Type=simple ExecStart=/usr/sbin/phc2sys -a -rr [Install] WantedBy=multi-user.target ### ptp4l ### debian@beaglebone:~$ cat /lib/systemd/system/ptp4l.service [Unit] Description=Precision Time Protocol (PTP) service Documentation=man:ptp4l [Service] Type=simple ExecStart=/usr/sbin/ptp4l -f /etc/linuxptp/ptp4l.conf -i eth0 [Install] WantedBy=multi-user.target debian@beaglebone:~$ cat /etc/linuxptp/ptp4l.conf [global] # # Default Data Set # twoStepFlag 1 slaveOnly 0 priority1 128 priority2 128 domainNumber 0 utc_offset 37 clockClass 128 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 # # Port Data Set # logAnnounceInterval 1 logSyncInterval 0 logMinDelayReqInterval 0 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval 4 neighborPropDelayThresh 20000000 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 net_sync_monitor 0 tx_timestamp_timeout 1 use_syslog 1 verbose 0 summary_interval 1 kernel_leap 1 check_fup_sync 0 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 0.0 first_step_threshold 0.00002 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # network_transport UDPv4 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0x20
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
