[ntp:questions] nmea and initial large offset
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
>>> 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