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

Krejci, Pavel pavel.krejci at siemens-enterprise.com
Wed Jun 23 09:04:58 UTC 2010


Hello Dave,

________________________________
From: David L. Mills [mailto:mills at udel.edu]
Sent: Wednesday, June 23, 2010 4:42 AM
To: Krejci, Pavel
Cc: questions at lists.ntp.org
Subject: Re: Reference clock driver for /dev/rtc

Pavel,

It's not as simple as that. Normally, ntpd uses settimeofday() once per hour to set the system clock, which has the side effect of setting the RTC. Obviously, you don't want that. If the RTC refclock is enabled, that has to be disabled, so some kind of interlock must be devised. This can be a tricky business and have unintended consequences if something or other fails.  The interlocks with the PPS signal come to mind.
Do you mean the 11 minute mode in Linux, when the system time is periodically written to the rtc in 11 minute intervals? This is triggered by the synch status (time_status variable in the kernel). I've solved this by periodically resetting this synch status in my refclock driver.

You are correct in that the RTC has in general far better temperature compensation than either the system clock or the TSC/PCC counter. However, its resolution is generally far worse. Even so, the lowpass character of the clock discipline masks this so actual delivered system time should be quite good. Chapter 15 of my new book due in September contains an extensive discussion on these issues.
Theoretically the worst RTC resolution is 1 second, but usually if offers update IRQ whenever the "seconds" counter changes. And this gives good resolution for my system. Attached is the /dev/rtc peerstats from my qemu guest system. The clock offset keeps under 1 milisecond which is enough for our purposes. I will check your book when published.

Regards
Pavel

Dave

Krejci, Pavel wrote:

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<mailto:questions at lists.ntp.org>
Subject: Re: Reference clock driver for /dev/rtc

On 2010-06-16, Krejci, Pavel
<pavel.krejci at siemens-enterprise.com><mailto: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<mailto:questions at lists.ntp.org>
Subject: Re: Reference clock driver for /dev/rtc

On 2010-06-15, Krejci, Pavel
<pavel.krejci at siemens-enterprise.com><mailto: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<mailto:questions at lists.ntp.org>
Subject: Re: Reference clock driver for /dev/rtc

On 2010-06-14, Krejci, Pavel
<pavel.krejci at siemens-enterprise.com><mailto: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.












_______________________________________________
questions mailing list
questions at lists.ntp.org<mailto:questions at lists.ntp.org>
http://lists.ntp.org/listinfo/questions


-------------- next part --------------
_______________________________________________
questions mailing list
questions at lists.ntp.org
http://lists.ntp.org/listinfo/questions


More information about the questions mailing list