[ntp:questions] Start of new GPS 1024 week epoch

Magnus Danielson magnus at rubidium.dyndns.org
Sun Aug 18 13:30:51 UTC 2013


On 08/18/2013 12:16 PM, Rob wrote:
> David Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
>> On 18/08/2013 09:19, Magnus Danielson wrote:
>> []
>>> If you want this feature to be disabled by default, you end up with
>>> causing the disruption that the fix is there to avoid. Few will know
>>> that they need to fiddle with that bit, and it becomes a continuous
>>> support thing, rather than letting the default being that it fixes the
>>> problem and then let the really cautious people turn it off. Default
>>> disabled is a bad idea.
>>>
>>> Yes, you change the default behaviour of NTP this way, but it's done
>>> because it has been analyzed and it's more likely to fix a problem than
>>> cause a problem for the majority of the users.
>>>
>>> Cheers,
>>> Magnus
>> I'm simply saying that I'm happy with NTP as it is now, and that if any 
>> /new/ feature is added, it should be optional and disabled by default. 
>> The new feature should /only/ apply to GPS sources.
> Perhaps the code should be restructured so that the "network time protocol"
> remains part of ntpd, and local reference clocks are moved out into
> processes that are more loosely coupled than drivers are now.
>
> A fix like this belongs in a driver for GPS, not in the main code that
> supports networking and synchronization of the local clock.
>
> Only the shared memory interface currently has functionality like this,
> and it has some limitations in the information it can convey.  If this
> interface is improved, all the local clock drivers can be moved out
> into separate processes and everyone can tinker his driver to fix problems
> like this one.  It will also be easier to release a fixed driver once
> a problem like this suddenly appears.
This is relevant for any driver interfacing a GPS. It's the correction
of time as it comes into NTPD.

Cheers,
Magnus


More information about the questions mailing list