[ntp:hackers] Receiving smeared time

Harlan Stenn stenn at ntp.org
Sun Jun 28 02:44:43 UTC 2015


Hi DeFrance,

"DEFRANCE CLARKE" writes:
> Harlan,
> 
> 1. I appreciate all the work you and others have put into this effort.

Thanks!

> 2. I like the simple RefID scheme. It is easy to understand and
> conveys the maximum information.

I agree, and it also seems to suck the least of all of the other
proposals.

I'm not thrilled that it may make loop detection useless during the time
it takes to apply the smear, but I also believe most loops will be
detected within a few polls anyway.

> 3. What should NTPD do if receiving a "smeared" time?
>   a. By default, drop the packet.

Why?  If we're smart enough to know about this case, the premise is that
if the other machine is configured as a 'server' we want to receive time
from that machine.  At worst we should accept the time and "undo" the
correction, right?  But why would you have some upstreams configured as
"peers" and others as "servers"?

The intent of this approach is "Disseminate smeard times to our client
population.".

>   b. If configured to accept smeared time, use the packet.

This would be the "server" case.

>   c. i.e. unless both server and client are configured for smeared time,
>      it won't happen.

Smeared time will arrive:

- if an upstream server has:
- - was built specifially to offer smeared time to clients
- - the "client" list these sources as "server" machines.
- - I believe (and haven't looked) that "pool" machines will do this,
    too.

>   d. Obviously if the client has not been updated to be smear-aware
>      it will accept the packet depending on the other acceptance
>      criteria.

Yes.

> 4. My opinion, this is enough for this leap second.  Remember 99% of
>    users will not update before then.

Yes.

I still think we need to add the absolute value of the smear correction
to the root dispersion in this case, and ... something else I'm open to
remembering.

> 5. Later:
>   a. Allow configuration the smear start and stop time.
>   b. Decide on RefID for IPv6.

This last one is easy - I just have to write it up and submit it to the
IETF.

H
-- 
> ------ Original Message ------
> Received: 02:31 PM PDT, 06/27/2015
> From: Harlan Stenn <stenn at ntp.org>
> To: hackers at ntp.org
> Subject: [ntp:hackers] Receiving smeared time
> 
> > Folks,
> > =
> 
> > I've put a staggering amount of time and effort into NTP lately, and a
> > lot of effort has been put in by a handful of other volunteers,
> > including Martin Burnicki, Juergen Perlinger, Frank Kardel, and several=
> 
> > others..  An amazing amount of work remains to be done.
> > =
> 
> > The latest ntp code has the optional ability (disabled by default) to
> > provide "smeared" time for the leap second correction.  This smeared
> > time is only offered in response to client time query requests.
> > =
> 
> > Since there is no way in NTPv4 or earlier to note that the timestamps i=
> n
> > a packet contain a smear adjustment, one if the things I just added was=
> 
> > a change to the REFID for these packets.  If an NTP timestamp packet
> > contains a refid of the form 254.a.b.c then the 24 bits provided by
> > a.b.c are a 2:22 integer:fraction that contains the amount of the smear=
> =2E
> > =
> 
> > If ntpd gets a timestamp with one of these refids, what should it do?
> > =
> 
> > There's very little time left to make changes before the leap second.
> > =
> 
> > What *needs* to be done before the leap second?
> > =
> 
> > What comes later?
> > -- =
> 
> > Harlan Stenn <stenn at ntp.org>
> > http://networktimefoundation.org  - be a member!
> > _______________________________________________
> > hackers mailing list
> > hackers at lists.ntp.org
> > http://lists.ntp.org/listinfo/hackers
> 
> 
> 


More information about the hackers mailing list