Re: ntpd not setting time under kvm-qemu
On 2014-09-21, Markus Wernig wrote: > But the system keeps constantly loosing time, at a rate of about two > seconds per minute (which of course makes it unusable). adjtime(2) can only skew the clock by a maximum of +/- 5ms each second. > Sep 21 13:12:37 secure ntpd[26259]: adjusting local clock by 53.514878s > Sep 21 13:14:47 secure ntpd[26259]: adjusting local clock by 52.869489s > Sep 21 13:16:27 secure ntpd[26259]: adjusting local clock by 54.363131s > > The offest is correct, by the time it writes that message, the system > clock is really that much off the real ntp time. Only that the local > clock never does get adjusted. It gets adjusted, but the drift exceeds the largest possible adjustment. > The clock frequency is also never adjusted, and ntp.drift remains > untouched. ntpd will not establish the frequency correction until the clock has been synced. In short, your system loses time faster than ntpd can correct. -- Christian "naddy" Weisgerber na...@mips.inka.de
ntpd not setting time under kvm-qemu
Hi all I have 5.5 i386 running under kvm-qemu, using ntpd to sync time. But the system keeps constantly loosing time, at a rate of about two seconds per minute (which of course makes it unusable). When starting ntpd with the "-s" flag, it successfully sets the system time and initializes /var/db/ntp.drift. But after that it does no longer set the system time, even if it says so in syslog: Sep 21 13:12:37 secure ntpd[26259]: adjusting local clock by 53.514878s Sep 21 13:14:47 secure ntpd[26259]: adjusting local clock by 52.869489s Sep 21 13:16:27 secure ntpd[26259]: adjusting local clock by 54.363131s The offest is correct, by the time it writes that message, the system clock is really that much off the real ntp time. Only that the local clock never does get adjusted. The clock frequency is also never adjusted, and ntp.drift remains untouched. In order to run the system at all under qemu I had to disable mpbios in the kernel. Could this have caused that effect? Or is anyone aware of this being a problem under kvm-qemu and i386 (no such problems with 5.5 or -current amd64)? Thanks /markus
