In article <[EMAIL PROTECTED]> Marton Fabo <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
