[ntp:questions] Reference clock driver for /dev/rtc

Krejci, Pavel pavel.krejci at siemens-enterprise.com
Tue Jun 22 12:08:29 UTC 2010


Hi,

well, then, do you find it useful? How should I proceed to contribute into ntpd project?

Thanks
Pavel

> -----Original Message-----
> From: unruh [mailto:unruh at wormhole.physics.ubc.ca]
> Sent: Thursday, June 17, 2010 11:48 AM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] Reference clock driver for /dev/rtc
>
> On 2010-06-16, Krejci, Pavel
> <pavel.krejci at siemens-enterprise.com> wrote:
> > Hi,
> >
> >> -----Original Message-----
> >> From: unruh [mailto:unruh at wormhole.physics.ubc.ca]
> >> Sent: Tuesday, June 15, 2010 7:15 PM
> >> To: questions at lists.ntp.org
> >> Subject: Re: [ntp:questions] Reference clock driver for /dev/rtc
> >>
> >> On 2010-06-15, Krejci, Pavel
> >> <pavel.krejci at siemens-enterprise.com> 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:unruh at wormhole.physics.ubc.ca]
> >> >> Sent: Tuesday, June 15, 2010 2:23 AM
> >> >> To: questions at lists.ntp.org
> >> >> Subject: Re: [ntp:questions] Reference clock driver for /dev/rtc
> >> >>
> >> >> On 2010-06-14, Krejci, Pavel
> >> >> <pavel.krejci at siemens-enterprise.com> 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.
> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>




More information about the questions mailing list