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

unruh unruh at wormhole.physics.ubc.ca
Thu Jun 17 09:48:05 UTC 2010


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