If you notice in your ntpq dumps you did, you have >400ms of jitter. That is a hell of alot.
I dunno if it makes a difference but you used 3 servers from the same
edu, and they have 90ms on them, shouldn't matter, if they where the
only ones with jitter I would replace them, but all 4 of your entries
have high jitter.
Jitter stops ntp from doing it's job properly. I'm not sure what is
causing you jitter to be so bad, but it's caused by the delay amount
changing from packet to packet. The delay should stay consistant (like
a ping time). If it keeps bouncing all over the place, ntp can't
figure out what time it really is, cause it doesn't know how long that
packet was on the network. You can safely ignore offset, it is just
how much different your clock is from what the other computer is.
Try adding some of the pool servers in there, like: server 0.us.pool.ntp.org server 1.us.pool.ntp.org server 2.us.pool.ntp.org
I assume your in the us atleast, if not you could change to eu or
something (check www.pool.ntp.org)
A few samples from my dom0's (and noticing lots of people changed from
st 2/3 up to 1 lately it seems)
remote refid st t when poll reach delay offset jitter============================================================================== *18.26.4.105 .PPS. 1 u 813 1024 377 7.939 -2.960 0.937 +64.90.182.55 .ACTS. 1 u 487 1024 377 9.375 4.435 0.670 +204.152.184.72 .GPS. 1 u 339 1024 377 82.343 -6.345 0.956 -10.1.11.62 206.246.118.250 2 u 3 16 377 0.191 0.965 0.085 10.1.11.69 10.1.11.61 3 u 15 16 376 0.146 0.448 0.036
remote refid st t when poll reach delay offset jitter============================================================================== *206.246.118.250 .ACTS. 1 u 642 1024 377 11.615 1.992 0.934 +209.51.161.238 .CDMA. 1 u 955 1024 377 9.701 -0.562 0.200 -128.105.39.11 128.105.201.11 2 u 665 1024 377 37.122 -2.228 0.634 -10.1.11.61 18.26.4.105 2 u 10 16 376 0.184 -0.916 0.247 +10.1.11.69 10.1.11.61 3 u 11 16 376 0.215 -0.542 0.023
remote refid st t when poll reach delay offset jitter============================================================================== +128.59.16.20 204.123.2.5 2 u 40 64 377 1.873 -0.291 0.092 -198.82.1.203 198.82.247.164 2 u 32 64 357 16.517 -3.454 0.300 -128.2.129.21 69.10.36.2 3 u 41 64 377 28.699 4.447 0.094 -132.236.56.250 129.6.15.29 2 u 2 64 377 9.290 -2.892 0.295 *10.1.11.61 18.26.4.105 2 u 1 16 377 0.161 -0.455 0.051 +10.1.11.62 206.246.118.250 2 u 5 16 377 0.206 0.546 0.020
Quoting PGNet Dev <pgnet.dev+dovecot@gmail.com>:
just fwiw, as of 10/06/09 19:03:27 still no errors. apparently, time's moving forward again ...
so, it seems the config above works. why some others have NOT seen the same problems, remains for me a bit of a mystery.