...
rm $ISFF/projects/CABL/ISFF/logs/R_derived_last.txt
Time keeping
The DSMs each have a GPS with a pulse-per-second signal. Using NTP reference clock software, each DSM is then a stratum 1 time server. NTP generally reports that their system clocks have less than a 50 micro-second offset from the times of the GPS PPS signal.
To query the system clock on a tower DSM from flux, use the ntpq -p command, for example 50m:
ntpq -p 50m
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 20d 64 0 0.000 0.000 0.000
oGPS_NMEA(0) .GPS. 0 l 5 16 377 0.000 -0.001 0.031
The above shows the system clock is offset from the GPS by -0.001 milliseconds. The "reach" value for GPS_NMEA should be 377 (octal value of all 1's). The reach for the LOCAL clock is always 0.
flux is configured to use all 6 DSMs as network time servers. flux runs chrony, a NTP client. To display the current chrony status, use chronyc sources:
chronyc sources
210 Number of sources = 6
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 50m 1 10 377 558 -298ns[+5000ns] +/- 742us
^+ 100m 1 10 377 179 +52us[ +52us] +/- 662us
^+ 150m 1 10 377 219 +2000ns[+2000ns] +/- 739us
^* 200m 1 10 377 338 +9656ns[ +15us] +/- 671us
^+ 250m 1 10 377 439 +5677ns[ +11us] +/- 732us
^+ 300m 1 10 377 95 +11us[ +11us] +/- 794us
The above shows that the clock on flux agrees to within a maximum 52 microseconds with each DSM. The second character should be '*' (flux is sync'd to this server) or '+' (good server). Sometimes I've seen '-' (lately on 100m for some reason) indicating chrony does not have a high opinion of its time information.
The "reach" values should again be 377. If not, it means the DSM is not on the network, or its NTP server is not responding or sync'd to its GPS.