[ntp:questions] nmea and initial large offset

Richard B. Gilbert rgilbert88 at comcast.net
Sat May 8 00:26:43 UTC 2010

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!

> 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.

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!

> 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!

More information about the questions mailing list