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

Rob nomail at example.com
Sun Aug 18 10:16:07 UTC 2013

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.

More information about the questions mailing list