[ntp:questions] nmea and initial large offset

Richard B. Gilbert rgilbert88 at comcast.net
Sat May 8 14:06:34 UTC 2010


unruh wrote:
> On 2010-05-08, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>> Rob wrote:
>>> Andy Helten <andy.helten at dot21rts.com> wrote:
>>>> Rob wrote:
>>>>> Kalle Pokki <kalle.pokki at iki.fi> wrote:
>>>>>   
>>>>>> Yes, but reference clock drivers don't use the ntp timestamp. Take a
>>>>>> look at e.g. the SHM driver. There
>>>>>>     
>>>>> Is this piece of code something that our friend does not want to change
>>>>> because he believes it is doing the right thing?  Or is it merely badly
>>>>> written by a contributor and nobody got around to cleaning it up?
>>>>>
>>>>> I would say it is completely pointless to decompose a timeval timestamp
>>>>> into separate fields and then back.  That only costs CPU time and induces
>>>>> errors.
>>>> You should read the discussion in the bug report that was previously 
>>>> provided by Kalle:  https://bugs.ntp.org/417
>>>>
>>>> It includes justification from David Mills on why it works this way.  I 
>>>> don't know that his justification specifically addressed the inability 
>>>> to even force a quick sync with a refclock when it differs by more than 
>>>> 4 hours from system time (i.e. the CLOSETIME stuff).  To me, there is no 
>>>> justification for such behavior with respect to forcing a quick sync.  
>>>> In such cases, ntpd is saying to the user "I know best" but it turns 
>>>> that it doesn't.
>>> It sometimes gets a bit tiresome that mr. Mills always brings up his
>>> experiences with 20 year old systems to dictate what can be done with
>>> ntpd today.  He has seen clockchips (interestingly named TOY clocks by
>> TOY Clock or "Time Of Year Clock" is a Hardware clock present on, AFAIK, 
>> all models of DEC VAX and Alpha computers.  It runs on battery power 
>> when the system is powered down.  Many computers, including most PCs 
>> feature such a clock.  They generally do not keep time very well!
> 
>  but the rtc on pcs do provide the year. They may not keep time well,
> but do keep it to better than a year.
> 
>>> him) that don't provide the year, and hence the year should not be
>>> used by anything.  He has a clockdriver that does not provide the year
>>> and so no clockdriver should provide the year.
>>> But is this still true today?  I think any reasonable clock chip in use
>> The clock CHIP is not the problem.  The problem is that the quartz 
>> crystal that provides the "tick" is usually one that failed quality 
>> control at a wristwatch factory.
> 
> Who cares. It keeps time to seconds per month, and unless you switch off
> your computer for a century, that is 'good enough'
> to intialise the clock.
> 
>> If the manufacturer was willing to spend money he could build a clock 
>> that would not gain or lose more than three or four seconds per year.
>> Would you pay an additional $50 per PC in order to have such a clock?
>> I believe that most people don't care.  The only reason that most 
>> computers need a clock is in order to get the date right when you are 
>> using Quicken, or similar software, to write checks!
> 
> I have no idea how this answers the criticism. 
> 
> 
>>> today has the year information, and a reference clock like ntpshm has
>>> year info within the range of 32bit time_t just as well.  By the time
>>> that will be a problem, time_t will be 64bit I hope.
>>> We should not drive current users to despair (because they cannot set
>>> their clocks) just because of some problem that existed 20 years ago
>>> or will come up in 28 years time.
>>>
>>> With such an attitude against change, it often surprises me that there
>>> hasn't been a major fork of ntpd yet.
>> The source code for NTPD is available.  Fork away.  Or fork off!
> 
> Oh dear. A suggestion for improvement of a clear deficiency on ntpd is
> made and you come up with this. 

Please feel free to install your own "fix" for the deficiencies you 
perceive in NTPD and see how well it keeps time.  I know, you want 
SOMEBODY ELSE to do the work!  There may not be anyone else!




More information about the questions mailing list