[ntp:hackers] smearing the leap second

Terje Mathisen terje at tmsw.no
Wed Jun 24 06:50:23 UTC 2015


Danny Mayer wrote:
> I've been following this thread with interest and I have the following
> comments.
>
> 1) Stealing bits is wrong. That not a moral judgement but an
> architectural one. Whether you get them from the RefID or the fuzz bits

I agree, we have lots and lots of experience with protocols that started 
by stealing bits, i.e. all the US phone line formats which embedded 
control information inside the bit stream.
> of the timestamps you are not going to get what you want. If you take it
> from the RefID then the reference information will be incorrect and
> you've lost loop detection. Moreover it won't be usable unless it's a
> stratum 1 server and then you lose the information about the RefClock.
> If you take it from the fuzz bits you lose the purpose of those bits.
> There's actually a specific purpose to them. I don't remember all the
> details but they are important.

The question isn't "Is bit stealing bad?", but "Is bit stealing for a 20 
hour period once every 2-4 years worse than the alternatives?"
>
> 2) If you are following a smeared server then you should ignore the
> leapsecond notification since the smeared server is doing the work for
> you. If you are following one smeared server then all servers being
> followed have to be smeared. Furthermore you cannot perform smearing
> yourself.

Exactly right.
>
> 3) If this is for NTPv4 then an extension field is they way to go, not
> only for the notification of the smear campaign but the algorithm being
> used to perform the smear. The extension field would not be needed for
> normal operation.

For NTP4 such an extension field cannot and will not propagate through 
any intermediate (i.e. old) servers, and there is no way to query the 
final clients and figure out if they are smearing or not.
>
> 4) If we go to NTPv5 the information in the packet can be different but
> most of the above requirements would still be needed.

NTPv5 will need a new packet format, with a transparent way to add new 
features/extensions.
>
> 5) If an NTPv4 system receives an NTPv5 packet what does it do with the
> packet? Is is supposed to drop it, or respond with an NTPv4 packet but
> how will it interpret the contents of the NTPv5 packet? Will it think it
> has an unknown extension field?
This one is easy, the same problem was solved during all previous NTP 
version upgrades:

Any client specifies the maximum version it is willing to use/accept in 
the initial request packet, and all servers have always returned packets 
in the same format.

This has meant that clients have needed the ability to specify that a 
given (i.e. old) server should only be queried using v2 or v3 packets.

I expect v5 clients to have to specify v4 request formats to most 
servers, except for the pool servers which will probably be upgraded 
much faster than the average.

Terje


>
>
> Danny
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> http://lists.ntp.org/listinfo/hackers
>


-- 
- <Terje at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the hackers mailing list