[ntp:questions] all servers rejected

Per Hedeland per at hedeland.org
Fri May 18 01:03:11 UTC 2007


In article <cf489$464cacf4$50627cad$8457 at news.chello.hu> Marton Fabo
<mortee at ------------------> writes:
>
>Can anyone tell me why may ntpd just silently reject all the specified
>servers, and fail to set the system clock, without even dropping a note
>to the syslog?

It keeps trying, there's nothing to report...

>Actually I *don't* want to *understand* why it may think it's better for
>me not having clock sync at all than to sync to a "relatively
>unreliable" server. I just want it to do anything it can to keep sync as
>much as possible.
>
>I'm running a FC3 in a VMWare, and its clock gains huge times a day
>(>1hr). I don't have the time or intent to track down why it behaves
>like that, I just want it to remain within reasonable bounds without
>much fiddling.

Well, ntpd wasn't designed to operate under the extreme - or rather
broken - conditions that you have, so you'll have to do a bit of
tinkering, and it may not work anyway. First of all a drift of 1 hr per
24 hrs is 41667 ppm, which is of course way beyond the 500 ppm limit
under which ntpd can keep time by slewing only, so at best you would get
recurring backward steps of the clock.

But that doesn't seem to be your only problem - the offsets that are
reported in your "peers" output vary wildly between the servers, from
-68 secs to +20 secs, which can't be explained just by your huge drift
given that they're all polled at 64-second intervals. Since the actual
server times (checked from here) don't differ like that, either there is
something broken with your networking, or the vmware clock doesn't just
run way too fast but also hops about like crazy - probably the latter.

In any case having such a list of servers inside a vmware instance is
pretty bizarre - bothering stratum 1 and 2 servers on the Internet all
over Europe with the timekeeping on your virtual machine is rude if
nothing else. It should be quite sufficient to use the vmware host as
server - drop everything else, including the local clock which is
entirely pointless in this scenario. This could actually make things
work at least to the point where ntpd can consider stepping your clock,
since one problem is that it can't find any particular server to believe
given those varying offsets, and hence doesn't know what time to step it
to.

--Per Hedeland
per at hedeland.org




More information about the questions mailing list