On Mar 24, 2011, at 1:29 PM, Alby wrote: > Its a Virtual Machine at (openhosting.com). A long time ago it was > working fine, no errors or anything. Then out of the blue, these > problems started up. So who knows what happened. It just might be a > crazy clock.
Ah, you should have mentioned that it is a VM and not running on a physical machine. To quote something I've mentioned elsewhere: 1) Running ntpd in the Dom0/host ESX/host is very useful. Keeping good time there means that good time will be available to all of the VMs/guests via independent_wallclock = 0, vmx option tools.syncTime = true, etc. 2) Running ntpd in the Dom0/host ESX/host also means that system/kernel clock will or ought to be sync'ed, which means that the periodic updates to the RTC/TOD/TOY clock are also good. 3) Running ntpd in a DomU/guest is possible, however a DomU/guest OS cannot update the time seen in other DomUs/guests, and it cannot update the RTC/TOD/TOY clock. 4) Furthermore, ntpd in a DomU/guest may experience large jumps in time depending on the loading of the physical host, whether the VM is swapped out or otherwise suspended for long periods of time, etc. [ This is why the suggested ntp.conf's for DomU/guests use "tinker panic 0", and recommend not to use to undisciplined local clock. ] 5) I have yet to see an example where running ntpd in a DomU/guest kept better time than ntpd running in Dom0/host OS. 6) I have yet to see an example where ntpd running in a DomU/guest kept better time than using independent_wallclock = 0, tools.syncTime = true, etc if the Dom0/host OS is sync'ed. Because of the above, I've drawn the conclusion that "running ntpd's in the other DomUs/guest VMs is almost entirely pointless". Regards, -- -Chuck _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
