On 2010-06-15, Krejci, Pavel <[email protected]> wrote: > Hi, > > since I cannot use kvm-clock as the clock source (older guest kernel) I am > using pit as the clock source. According to my tests this is the most stable > clock source among tsc,hpet but still can drift. Since the qemu keeps the > /dev/rtc perfectly synchronized with the Host's system time it is a good time > source for the ntpd on the guest. The host itself is then sychronized via NTP > with the external time server. I don't know any other way how to read the > system time from the Host, please offer if you have some. >
I do not understand. If you driver can read the rtc, it can read the system clock instead. And virtual systems are terrible things to use ntpd on. ntpd cannot control something where the clock varies by more than 500PPM, and virtual systems, since they are shut down for variable lengths of time by the host, tend to have terrible clocks. The rtc can only be read in one second chunks. > The only disadvantage is that when the step time back must be done on the > Host, the /dev/rtc gets stuck (it is a monotonic clock) and the qemu must be > restarted. rtc is not a monotonic clock. It can be set to whatever time you want. Unless your hardware is different than what I am imagining. > > Regards > Pavel > >> -----Original Message----- >> From: unruh [mailto:[email protected]] >> Sent: Tuesday, June 15, 2010 2:23 AM >> To: [email protected] >> Subject: Re: [ntp:questions] Reference clock driver for /dev/rtc >> >> On 2010-06-14, Krejci, Pavel >> <[email protected]> wrote: >> > Hello, >> > >> > I have written the reference clock driver for /dev/rtc on >> Linux. We use it to synchronize the guest Linux system >> running in the qemu with the Host clock. If this is useful to >> someone else I would like to contribute to the NTP project. >> How should I proceed? >> > >> >> Why would you want to do that? The rtc is almost certainly >> worse than the system clock. Why not have the guest just read >> the host's system clock, rather than the rtc. >> >> >> >> _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
