| RE: [chrony-users] chrony not observing maxpoll - bug? |
[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]
I may have figured out what has been going on. The clients are connected via WiFi, and I am streaming audio to them as well. It appears that a significant fraction of the server queries are lost/dropped (or perhaps chrony throws them out for one reason or another) under this scheme. I arrived at this conclusion after performing the following: I set the polling to have a constant 8 second interval, and then I had a script produce the output from chronyc sources every 8 seconds. I looked at the Rx value (time last good response was received), which should be 8 seconds or less, depending on when in the cycle I happened to query it. If the value was over 8 seconds, this must be due to longer intervals between replies from the local server. Sure enough, with the audio streaming, this sometimes grew to over 60 seconds. I find that a little strange, because the server is on my own LAN and connected by a hardwire to the router. But perhaps because the channel is in constant use by the audio stream, which is assigned high priority by my router via Qos rules, the NTP packets might just not get through on a regular and “timely” basis. The solution I have put into place was to add a USB WiFi adapter to each client (an R-Pi 4). I use the Pi’s built in WiFi for NTP/chrony, and the USB adapter for the audio stream. I used the bindacqaddress directive to restrict chrony to the built-in adapter, and the audio stream can be directed to the other using my streaming audio software. Initial testing shows that very few server queries are dropped, so this is likely a good solution to my problem. The only thing that I might be able to tailor and improve is why and when chrony drops or invalidates server replies. If anyone has any advice in that regard I would like to know it. Thanks. -Charlie From: Charles Laub <charleslaub@xxxxxxxxxxxxx> 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. 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 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 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 35. 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. Let me know if there is some other info I can post that might be useful. Thanks, -Charlie |
| Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |