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

David L. Mills mills at udel.edu
Wed Jun 23 18:27:55 UTC 2010


Pavel,

Linux has many, many times broken the NTP model compatible with other 
systems such as Solaris and FreeBSD, among others. I have no trouble 
with that as long as whatever modifications are required in NTP to make 
the RTC driver work remain proprietary to Linux and never leak to other 
systems. I have no idea what the Linux 11-minute process is about, but 
it probably conflicts with the NTP 1-hour RTC alignment.

If your driver requires the Linux model, whatever modifications are 
required in the base code (#ifdefs) will not be supported here and may 
conflict with future developments. On the other hand, it could be, for 
example, that the RTC provide a 1-second interrupt similar to the PPS 
signal now. On that assumption the base code might have a feature that 
supports the RTC in much the same way the NMEA driver does now. That 
would be a generic solution and nicely fit the NTP.

Dave

Krejci, Pavel wrote:

> 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: [ntp:questions] 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
>>>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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>
>>>>>        
>>>>>
>>>    
>>>
>>_______________________________________________
>>questions mailing list
>>questions at lists.ntp.org
>>http://lists.ntp.org/listinfo/questions
>>  
>>
>




More information about the questions mailing list