| Re: [chrony-users] chrony not observing maxpoll - bug? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
As I mentioned, look in the measurement.log file to see how often the system
is being polled.
It is possible that the polls get so bad (or non-existant) that it keeps
trying to get 8 filter values to filter.
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
On Fri, 5 Feb 2021, Charles Laub wrote:
Background: I need to keep several machines well synchronized to my local NTP reference. This is for audio work, where playback needs to be tightly synchronized
between multiple computers. I previously used NTP for many years for this, but have recently switched to chrony to take advantage of its time smoothing and
filtering capabilities. I have a local "server" in my basement where the temp remains constant. It's a stable reference for other computers in my home. My
machines only poll only this one sever.
On various Linux clients, I am experiencing the following issue:
Chrony works as expected. Synchronization is achieved to high precision, e.g. tens to few hundred microseconds.
For a local chrony that is not good. The sync should be a few 10s not 100s of
microseconds.
I use a fixed polling interval by setting minpoll and maxpoll to e.g. 2
To keep track of what is going on I print out the last offset every 60 seconds in an ssh terminal session
I have noticed sometimes that this value gets "stuck". Here is some example output:
Last offset : +0.001239868 seconds
Last offset : -0.001022636 seconds
Last offset : +0.000342921 seconds
Last offset : -0.000313532 seconds
Last offset : -0.001234458 seconds
Last offset : -0.001234458 seconds
Last offset : -0.000906603 seconds
Last offset : -0.000906603 seconds
Last offset : -0.000036374 seconds
Last offset : -0.000354126 seconds
Last offset : -0.000354126 seconds
Last offset : -0.000010771 seconds
Last offset : -0.000010771 seconds
Last offset : -0.000010771 seconds
Last offset : -0.000010771 seconds
Last offset : -0.000411757 seconds
Last offset : -0.000411757 seconds
Last offset : -0.000411757 seconds
Clearly if the time is a hundred sec, the offsets will repeat since they have
not been updated.
It dawned on me later that this should not be happening, and when I looked at the chronyc output I found this:
pi@SPKR-left:~ $ chronyc tracking
Reference ID : C0A801FE (192.168.1.254)
Stratum : 4
Ref time (UTC) : Fri Feb 05 18:50:42 2021
System time : 0.000003940 seconds fast of NTP time
Last offset : +0.000011845 seconds
RMS offset : 0.000603218 seconds
Frequency : 6.857 ppm fast
Residual freq : +0.000 ppm
Skew : 0.059 ppm
Root delay : 0.039830066 seconds
Root dispersion : 0.003487853 seconds
Update interval : 535.4 seconds
Leap status : Normal
Notice the reported update interval of 535 seconds. But my server line includes the directives:
minpoll 2 maxpoll 2 iburst filter 8
The poll interval should remain at 2, and with filter=8 the poll should be reported every 32 seconds. 535 is certainly not the same as 32, so I suspect a bug.
This machine (Pi 4) is running chrony version 3.4, and another (an Intel box) is running 3.5. Both show an increase in the poll interval above 32 seconds in
chronyc. When this happens, the synchroncity becomes relatively poor so I would like to find a way to fix this problem if possible.
I suspect it is a server problem, not a client chrony problem.
Let me know if there is some other info I can post that might be useful.
The measurement logs would probably help-- but just an exerpt, not the whole
log. See if the polls really are every 4 sec and if the result is not
discarded for some reason. (the tests 123 567 ABCD should all be 1 for a good
sample)
Thanks,
-Charlie