After a search in this forum, I couldn’t find a similar situation as mine.
I have a server whose time is consistently a few ms off from its peers, bot ST1 and 2:
server (loc remote refid st t when poll reach delay offset jitter
==========================================================================================
192.168.z.a -192.168.z.c aaa.bbb.ccc.ddd 3 u 309 1024 377 0.272 9.275 1.759
192.168.z.a +192.168.z.b eee.f.g.hh 2 s 27 64 377 0.166 7.333 0.219
_xxxx::yy *xxxx::123: .GPS. 1 u 459 1024 377 36.360 6.783 2.814
_xxxx::yy +xxxx::e iii.jjj.k.l 2 u 842 1024 377 30.356 5.561 1.871
_xxxx::yy -xxxx::4011 mmm.n.ooo.pp 2 u 825 1024 377 36.003 9.773 1.842
This has been going on for days, even after wiping out the drift file and restarting the daemon. However, this server has been in sync before. Recently, I tried to add the huff and puff filter, with no results.
Please send ntpq -npcrv output again without obfuscating the IP addresses. There is no risk to you by sharing IP addresses, and it makes it harder to help you by obfuscating them. Including your pool IP address would help as well, that way we can look at the raw stats in the CSV log.
For what it’s worth, it’s not uncommon to see graphs like that simply due to delay because of distance from the Newark monitoring station. Here’s one of mine: https://www.ntppool.org/scores/150.101.186.48 - it’s basically always less than 1 ms offset from LAN peers, but delay to the monitoring station changes the view from outside.
That looks pretty OK. Your frequency, jitter, & wander values are all reasonably low, and your root delay/dispersion is not terrible. I think it’s likely that this is normal behaviour for your server.
Irrelevant or not, in recent 2 or 3 weeks my stratum 1 server was observed like this:
Being a server synced against GPS PPS, the offset hardly went above or below 10ms before. I suspect there was some trans pacific routing anomaly but I cannot confirm it.
Hi, is it the local offset (6.783) or the pool offset you’re concerned about? As @paulgear says, if it’s the pool offset I wouldn’t worry about it. If it’s the local offset then as you say the server was in sync before and it’s on the same LAN as other in sync servers, what’s changed or is different about this server? The delay to the selected peer looks higher on this server (36.360) than the other two (9.691 and 17.415) but not excessively so. Does this server have a highly loaded network interface? I’ve seen it before when a network cables affected traffic - both dodgy cables or connectors not fully inserted. Without the real IP details it’s not clear if all three servers are syncing to the same external source or not.
I am not worried about what the monitoring stations see, but about the local offset.
The peer of 192.168.z.c is also seen by 192.168.z.b, but it prefers a closer one.
It’s a new NAS, which locked the time as expected at first, but after a few days started to veer off and never got back.
As a NAS, it does see a lot of local traffic during the day, but the offset doesn’t get any better during the night. The other servers see only moderate traffic.
I’ve never seen anything like it in all my years using NTP.
Nothing else changed between when it was locked ok and now? My bets would still be network traffic / config / physical connection. Might be worth setting the peer list on z.a the same as one of the other two to see if they both give similar figures and prefer the same server. Otherwise maybe plug z.a into z.b or z.c’s network cable and see if that has any effect…
It doesn’t seem to be the case, since it once synchronized with little offset and other servers in the same network see the same IPv6 servers with little offset. Shouldn’t NTP correct for network delays?
The NTP protocol well compensate big delays. However, it assumes that the delay is symmetric (lack of priory knowledge about delay asymmetry). The delay asymmetry leads to fix offset. That is not visible, unless the server has other reference, for example different delay asymmetry due to other routing condition with a different protocol.
Do the offsets consistently have the same sign (positive)? That would be strange indeed. Any chance there is a different NTP client running on the system?
z.a and z.b share the same configuration file, except for the peers and servers. Other parameters disable logging, specify the drift file, restrictions and the one tinkering that I added a couple of days ago to see if it could bring z.a and z.b closer: huff n puff.
