Quoting Rob (nom...@example.com): > > What is actually wrong with running ntpdate to initially sync a clock? > The problem is that you give the clock an initial kick that ntpd does > not know about, and it tends to have problems correcting that. > This sometimes results in the problems you are seeing.
But i cant use ntpdate is ntpd is still running because the socket/port is already bound. But this possibly follows up on your 'the OS might keep track of drift/frequencies'-quote at the end of your mail. I'll keep it in mind. > >> c) It seems that you have an ntp.drift file which contains "500"! > > Indeed i did. That file was probably written by ntpd after the first run > > going completely haywire. I removed it from the configuration. > Did you stop ntpd, then remove the file, then start ntpd again? Yes. ;) > I know on VMware it works "OK", but for Windows that "OK" is never nearly > as good as for Linux. A Linux system will remain within a few ms, for > Windows 60ms is not bad at all. Can others on this list running ntpd on Windows concur? > Also not that on Linux, the more you poke it the more it starts to > misbehave. I think ntpd feeds correction data into the kernel that it > remembers in memory, but the kernel remembers it between boots. Yeah, i'm aware that ntp needs time (*hurhur*) to 'settle down'. -- | Clothes make the man. Naked people have little or no influence on society. | 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
