[ntp:questions] nmea and initial large offset

unruh unruh at wormhole.physics.ubc.ca
Sat May 8 07:44:34 UTC 2010

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. 

More information about the questions mailing list