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

David L. Mills mills at udel.edu
Sat Jun 26 15:07:33 UTC 2010


Bill,

Another case in which the engineering model in Linux and NTP are not 
compatible. Neither is necessarily wrong, just different. The following 
issues are known to me.

1. The Linux kernel discipline code adapted from my Alpha code of the 
1990s does not account for the frequency gain at other than a 100-Hz 
clock. With a 1000-Hz clock this results in serious instability. I 
pointed this out some years ago and it is a trivial modification, but so 
far as I know it has not been fixed.

2. The Linux adjtime mechanism inserts an extra pole in the impulse 
response, presumably to speed convergence when relatively large 
adjustments are made. This makes NTP unstable at the larger poll 
intervals when the kernel discipline is not in use. Both the kernel and 
daemon discipline loops are carefully designed according to sound 
engineering principles for optimum response, but the extra pole defeats 
the design.

3. The calling sequence for the ntp_gettime() system call is 
incompatible with current use. As a result, access to the TAI-UTC offset 
by application programs is not available.

4. As in the current instance, management of the RTC and system clock is 
incompatible. This issue should be reviewed in the context of the 
various models, whether the kernel or daemon discipline is in use and 
whether the system is awake or sleeping.

There are probably others and they probably could be resolved to insure 
a consistent model between Linux and other operating systems.

Dave

unruh wrote:

>On 2010-06-23, David L. Mills <mills at udel.edu> wrote:
>  
>
>>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.
>>    
>>
>
>Linux, depending on the setting of a flag in the adjtimex setup, sets
>the rtc from the system time once every  11 min. . This is a disaster if
>you have a procedure to discipline the rtc (eg hwclock, or chrony) and
>the "sychronization " flag must be kept unset to prevent this behaviour.
>On most systems the rtc is used to set the clock whent he computer is
>down . Ie, the rtc in those cases CANNOT be disciplined. All you can do
>is to determine the offset and drift rate of the rtc to make the use as
>accurate as possible when the system comes up again. It is very hard to
>detrmine the drift rate of a clocck that keeps getting reset
>To then use the rtc mechanism in a VM seems to me to be overloading the
>mechanism, making it hard to anything reasonable with it. 
>
>
>  
>
>>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
>>>> 
>>>>
>>>>        
>>>>
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>http://lists.ntp.org/listinfo/questions
>  
>




More information about the questions mailing list