Hi have just noticed msltime.irl.cri.nz. and msltime2.irl.cri.nz. have developed a 180 second offset from GPS-based ntp sources. As far as we can tell, the GPS-based sources are more likely right than the msltime servers. Can anyone shed any further light on this? cheers, John Rumsey
have just noticed msltime.irl.cri.nz. and msltime2.irl.cri.nz. have developed a 180 second offset from GPS-based ntp sources.
Yes. I see that their time is out too. We sync to msltime with prefer .... # ntpdate -d msltime.irl.cri.nz 21 Mar 20:40:35 ntpdate[700]: adjust time server 131.203.16.6 offset -0.324694 sec # ntpdate -d ntp.massey.ac.nz 21 Mar 20:41:09 ntpdate[705]: step time server 130.123.2.99 offset 179.678788 sec I have just contacted someone from IRL. They had a power outage at their Gracefield site today and it's likely that something has not reset properly. The appropriate person from MSL will get onto fixing this asap. -- Roger Williams, GNS Science xyzzy
On 21/03/2010, at 7:02 PM, John Rumsey wrote:
Hi
have just noticed msltime.irl.cri.nz. and msltime2.irl.cri.nz. have developed a 180 second offset from GPS-based ntp sources.
As far as we can tell, the GPS-based sources are more likely right than the msltime servers.
Can anyone shed any further light on this?
It seems strange that both clocks would get out of sync, unless they have forced it to use a common timesource and it broke or something. 180s sounds like the GPS source disappeared and it fell back to the system clock which wasn't being updated. Roger Williams mentions using 'prefer'. Why? Normal operation is to come up with a list of truechimers ('good' clocks) and then get an average time over all of them, and use that. If you use prefer, you are tied to the preferred clock only, and then the remaining truechimers are a backup. That means if you lose connectivity to your preferred host - or worse, it starts to flap - you get time skewing all over the place. That's a bad thing. Prefer is designed for networks that have a few local clocks that you would prefer to use, and then some remote clocks on far away networks. The NTP documentation suggests that you might use this if you are on the Moon for example, and you want to prefer a Moon-based timesource over an Earth based one as it would be more than a couple of seconds away. I give this example because it doesn't mean you should use 'prefer' to prefer some .nz host because it's on our end of a long fat pipe - NTP deals with this by design, and lots of people forcing the use of local clocks is somewhat analogous to inbreeding. Ideally, you have 4+ sources configured, all coming from different sites/locations/devices, which allows you to lose one due to a network problem or something and still have the ability to remove an outlier and keep accurate time. Configuring 4 sources with two of them being these CRI sources is, I would say, a misconfiguration. Make sure you configure as many sources are you can stomach, and leave out 'prefer' and other things. -- Nathan Ward
participants (3)
-
John Rumsey -
Nathan Ward -
Roger Williams