1

Questions are at the bottom.

When adding a time stamp based on the Pi's system time to a data file, I'd like to include some information about how reliable that time is.

For example, if the Pi has not yet made an internet connection since power up, the system time will be quite wrong by hours, days, or worse. If the last opportunity for synching to ntp servers was say 24 hours ago, it could potentially be off by many seconds, and if it were ten minutes ago, it's "good" as far as I'm concerned.

I'm using the following python to capture all of the lines in the response so I can decide later how to interpret them, the [2:] suppresses the header of column labels

stat, msg = commands.getstatusoutput("sudo ntpq -p")

for line in msg.splitlines()[2:]:
    print line:

After disconnecting the WiFi, I captured a few responses. According to the page 22.13. Checking the Status of NTP the column labeled when is "how long since last poll (in seconds)" and it increases with time as expected. But I don't understand why between 155 and 434 seconds that "jitter" changes, or between 434 and 687 seconds "delay" changes.

Right now I'm classifying that as an inconsequential bug and ignoring it. To me, the value of "when" is most important

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================


*59.124.29.241   118.163.81.61    3 -  155   64    4   15.729   -0.961  17.536
 103.226.213.30  .PPS.            1 -  155   64    4   15.423   -0.126  18.942
 61.216.153.104  118.163.81.63    3 -  155   64    4   15.871    0.996  16.849


*59.124.29.241   118.163.81.61    3 -  434   64  100   15.729   -0.961  19.605
 103.226.213.30  .PPS.            1 -  434   64  100   15.423   -0.126  18.942
 61.216.153.104  118.163.81.63    3 -  434   64  100   15.871    0.996  18.834


 59.124.29.241   118.163.81.61    3 -  687   64    0   99.582  -37.818   0.000
 103.226.213.30  .PPS.            1 -  687   64    0   99.470  -38.008   0.000
 61.216.153.104  118.163.81.63    3 -  687   64    0  100.017  -36.608   0.000

After turning WiFi on again and letting it run for a bit, I see the following, which suggests that it's periodically checking.

+59-124-29-241.H 211.22.103.157   3 u   58   64  377   15.857    1.084   1.112
*30-213-226-103- .PPS.            1 u   62   64  137   16.268    1.319   3.777
+61-216-153-104. 118.163.81.63    3 u  132   64  376   16.529    1.836   3.589


+59-124-29-241.H 211.22.103.157   3 u    7   64  377   15.857    1.084   3.690
*30-213-226-103- .PPS.            1 u   10   64  277   16.484    1.211   3.743
+61-216-153-104. 118.163.81.63    3 u   13   64  375   16.529    1.836   3.678

From an earlier experiment, I also received responses like:

+61.216.153.104  211.22.103.157   3 u    8   64  377   18.411   -1.238  16.884
+61.216.153.106  211.22.103.157   3 u   13   64  377   18.180   -0.263   0.915
-59.124.29.241   211.22.103.157   3 u   11   64  377   22.955   -2.006  16.754
*103.18.128.60   140.112.2.189    2 u    7   64  377   17.831    1.108  26.451

and in a separate test, I obtained the following unusual report:

+lithium.constan 18.26.4.105      2 u   18   64    1  216.854   -3.978   1.724
*30-213-226-103- .PPS.            1 u   18   64    1   19.176    1.233   1.815
+59-124-29-241.H 118.163.81.62    3 u   15   64    3   15.366   -1.471  17.176

edit 1: I've taken a look at Install NTP on CentOS which turned up in a search for help trying to understand what "lithium.constan" meant, and I found the command:

ntpdc -c sysinfo

When I use it, I get the following output

system peer:          30-213-226-103-static.chief.net.tw
system peer mode:     client
leap indicator:       11
stratum:              2
precision:            -20
root distance:        0.01585 s
root dispersion:      0.01375 s
reference ID:         [103.226.213.30]
reference time:       de849d47.0cf50a40  Sat, Apr 21 2018  1:09:27.050
system flags:         auth monitor ntp kernel stats 
jitter:               0.001526 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s

What caught my eye is the "stability" measurement. I'll let it run for a while to see if it becomes non-zero, hoping it might address Question 2 below.

edit 2: Looking at the question timed out, nothing received on ntpdc> loopinfo? I found the command

ntpdc -c loopinfo

Which gives me

offset:               0.000000 s
frequency:            -4.696 ppm
poll adjust:          6
watchdog timer:       372 s
ntpdc> 

I've turned the WiFi off about five minutes ago so that explains the watchdog timer being 372 seconds. Is the value for frequency -4.696 ppm what I'm looking for?

Question 1: Is using the lowest value for "when" a reasonable way to gauge roughly how long it's been since the system time has been checked against internet servers?

Question 2: Does the ntp daemon make an estimate of system clock drift rate available in any way? If it's say 10 ppm or 100 ppm, is this reported somehow?

Question 3: What do the characters in the first column such as '+', '*', '-', or absence thereof indicate?

System: using Raspbian GNU/Linux 8 (jessie)

  • 1
    What OS? Raspbian is ambiguous. – Milliways Apr 20 '18 at 11:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.