Hi, well, then, do you find it useful? How should I proceed to contribute into ntpd project?
Thanks Pavel > -----Original Message----- > From: unruh [mailto:[email protected]] > Sent: Thursday, June 17, 2010 11:48 AM > To: [email protected] > Subject: Re: [ntp:questions] Reference clock driver for /dev/rtc > > On 2010-06-16, Krejci, Pavel > <[email protected]> wrote: > > Hi, > > > >> -----Original Message----- > >> From: unruh [mailto:[email protected]] > >> Sent: Tuesday, June 15, 2010 7:15 PM > >> To: [email protected] > >> Subject: Re: [ntp:questions] Reference clock driver for /dev/rtc > >> > >> 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. > > I am not reading the Host's /dev/rtc. I am reading the > Guest's /dev/rtc, which is synchronized with the Host's system clock. > > > > OK, if that is the way your virtual system works, (Ie it > delivers the system time via /dev/rtc) then so be it. I would > say it is terrible, since it uses a predefined item ( rtc) to > deliver something totally different ( the system time of the > underlying host) rtc has numberous idiosyncracies, not oleast > being that it delivers only times with one second precision. > It also delivers an interrupt on one second boundaries, is > written by a displacement of .5 sec (Ie if you write the time > x to it, that time refers to the time of the rtc .5 sec in > the future. ) I assume that your /dev/rtc does not have all > thoese peculiarities. > > > >> 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. > > Yes the clocks like hpet or tsc are drifting very very much > and the ntpd cannot improve the resulting stability. But the > pit keeps quite well. With additional ntpd the resulting long > period clock stability is good - no exact measures done yet... > > OK. Not sure what the pit refers to in the case of the virtual system. > > > > >> The rtc can only be read in one second chunks. > > This does not matter, some radio clocks allow the same. > > > >> > >> > 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. > > This comes from the implementation of the /dev/rtc by the > qemu. I haven't investigated why. > > > > Regards > > Pavel > > > >> > >> > > >> > 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
