On 08/18/2013 12:16 PM, Rob wrote: > David Taylor <david-tay...@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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
