Simon Arlott wrote:
I'm not interested in SNTP so I wouldn't accept it as justifying why
it's wrong to have the leap bits set so early, it's RFC clearly states
Where exactly does it say in the RFCs that the leap bits can be set more
than 24 hours before the leap bit is inserted?
I still think you are misinterpreting the timing of the leap bits.
For example http://www.eecis.udel.edu/~mills/leap.html says "The NTP
leap bits are set by the protocol on the day of insertion". RFC 1305
says "The bits are set before 23:59 on the day of insertion and reset
after 00:00 on the following day." Note the phrase "on the day of
insertion", which to me sounds like the leap bits should be set between
00:00:00 - 23:59:00 on Dec 31st, remain to be set between 23:59:00 -
00:00:00, and be unset from 00:00:00 onwards on Jan 1st.
The logic you argue for, where the leap second would be signaled by
setting the leap bits back to zero, sounds like a very inaccurate way of
doing it. With a 1024 second poll interval, it could take up to 17
minutes for the client to notice that the leap second has occurred.
It's actually bit pointless discussing this anyway since NTP has no way
of specifying when the leap second occurs - only that unsetting the bits
indicate that it has occurred and by the time clients have received
leap=00 as it propagates through the network most of them would have
adjusted their clocks as if they were 1 second out.
I guess we are reading the spec differently then. To me, it seems
obvious that the leap second is added/removed on the last UTC second of
the day, if the corresponding leap bits are set immediately before that
time. Unsetting the leap bits after the leap has occurred just means
that there will not be another leap second between Jan 1st and Jan 2nd.
It would be interesting to know if the severs that are sending leap=01
have been configured to do so since the announcement of the leap second,
or if they've been manually configured like that for years.
I would like to know why they advertise the leap bits as well. Maybe
some reference clock implementation is flawed and sets the bits too
early and it then just propagates through to the higher stratum servers.
Maybe we should take this to comp.protocols.time.ntp anyway and ask the
guys who wrote the protocol and the reference implementation instead of
guessing here..
Tapio
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
