[ntp:hackers] Receiving smeared time

Harlan Stenn stenn at ntp.org
Sun Jun 28 03:54:42 UTC 2015


Harlan Stenn writes:
> Hal Murray writes:
> > 
> > stenn at ntp.org said:
> > > If ntpd gets a timestamp with one of these refids, what should it do?
> > 
> > Wrong question.  Almost all servers won't get updated, so the important 
> > question is what will old servers do with new packets?

Right question, just viewed and presented from a different perspective.
OK, I could have phrased it better.  It's been a long month.

The intent is that clients (ie, folks with 'server' or 'pool'
associations) of a server will be getting smeared time, because that's
what the servers are configured to provide.  If these clients don't know
any better, they'll follow the smeared time.  This is a "feature".

My question goes to the case where "a machine in the middle" has both
server and peer associations.  These machines are the likely ones to see
both smeared and unsmeared packets.

None of this should be news to anybody.

We all know that in a network where "mixed time" was available that
proper configuration was crucial.

We all know that some sites will have better tools than others for
managing their ntp.conf files.

We all know that if there are machines that are not part of this
management framework that these machines *may* misbehave if they have
unexamined ntp.conf files.

We all know that many folks don't properly monitor ntpd.

The above are the main reasons that I was so resistant to adding leap
smear support into ntpd.

Had we not added leap smear support we would be making life noticably
harder for competent and knowledgable people to easily manage their time
distribution.  That would suck for them.

By adding this capability we make life much easier for competend and
knowledgable people and organizations that *need* this feature to
effectively and efficiently provide smeared time to their "enterprise".

If they are not careful in this, they can make smeared time visible to
systems that do not expect this.  Problem will result.

Originally, there was no way to tell if a server was offering smeared
time or not.  With my patch, we can now tell - the refid will tell us.

I know there are a good number of folks who done *lots* of preparation
and testing for this event, and they are in Good Shape.

There are probably lots of folks who have not done any testing around
the leap second.  That's their choice, and maybe they'll be lucky.

If folks have implemented useful monitoring of their systems, at least
they'll know what their problems are, and they can decide what, if
anything, to do differently for next time.

There is a correlation between "participation" and "results".  If you
don't participate, you can expect to get whatever results you get.  If
you want different results, participate!

-- 
Harlan Stenn <stenn at ntp.org>
http://networktimefoundation.org - be a member!





More information about the hackers mailing list