[ntp:questions] Re: Public servers?

Tim Hogard thogard at abnormal.com
Thu Jul 31 15:57:26 UTC 2003

David L. Mills (mills at udel.edu) wrote:
: Time,
: I find your statement "If any of these routers are bothered by 300 
: packets per second, they have many other problems." absolutely mind 
: warping.

Let me define a few terms:
1) NTP server - devices like your  NTS-200
2) PC User - guy who wants his PC clock to be good enough so
he won't miss his favorite show on TV.
3) ISP router - device that sends packes around the Internet
and may just respond to a NTP packet if you send it one.
4) Hard core time users - You and anyone that has posted in this
group for more than a year.  My script isn't for them.

Any "ISP router" that will be overloaded by its downstream users
sending it NTP requests is going to have problems because if they
used pool.ntp.org, that very same router would send thouse NTP
requests out to the network and would send 20 times as many.  And
then double it because of the responces.  All using a local router
as an NTP clock is doing is moving the traffic away from the core
NTP servers to the routers on the edge of the Ineternet.

Think about my scripts as a way to find nearby routers that are
caching NTP.

:            This is normal flux for the NIST and USNO routers and our own 
: servers. The NIST and USNO folks really have no way to throttle the flux 
: without getting Congress and the stock brokers mad at them, but we 
: campus types are much more ugly when it comes to abusing priviledge.
If 99% of the people that are now setting their windows clocks using
their ISP's router, then even NIST and USNO wouldn't have a problem.

: We do have some NTP servers running web browsers as well and in these 
: cases have a very strict NTP access policy as specified in the public 
: lists. One of these servers happens to be a TrueTime NTS-200, which as 
: in all such boxes has an integrated web server. If you wiretap those 
: servers without handing down the access policy in the public lists, we 
: must consider you evil.
The only way my script will find that is if you access my
script from that box or you publish a BGP route saying
that box is a router.

: There are a number of defense mechanisms in ntpd as you may know, 
: including access controls, kiss-o'-death, call gapping, etc., some of 
: which are even effective against the boobs who lobby 256-packet bursts 
: within one second. The number and variety of these gangsters are growing 
: alarmingly fast.
And they will get worse.  Which is why it is importaint to get
ISPs to provide time services.  Which they are doing anyway
because its easier to tell a cisco router to use NTP than it is
to set its clock. 

: As the result of the U Wisconsin incident, RFC-2030 is under revision 
: right now and a draft has been circulated for comment. Your comments 
: about what should be in the public lists and on the web are well meaning 
: and we will do something about that.

NTP was built to solve a complex time problem that simply does not
exist for 99.99+% of the users on the net however because NTP is a
solution to a problem they have, NTP server operators get nailed.
For most time applications, round trip time is meaningless.  A
"set the clock" operation is one UDP packet to a nearby router
which sends back the time.

I would propose that a field be set up so say protocol 5 (is that
next consider it VerySimpleNTP), simply sends a packet back with
the current time with the assumption that none of the other issues
need to be considered.  That means a VSNTP overhead on a typical
NTP server is a syscal to get the time and one to send it in the
packet.  It would also make sense to put in the RFC that any router
that responds to public NTP packets is assumed to give concent for
its use only to thouse users who's packets would normally flow
through that router.  With those two things and Cisco IOS, its
faster to send back the current time than it is to forward the

: We have discussed the casual configuration issues many times in the NTP 
: developers group and come to no comfortable conclusion about scripts 
: like yours that discover ad hoc NTP servers. Best advice I have is to 
: not use those things at all and rely on pool.ntp.org to do the right thing.
People write scripts like mine because they don't know about pool.ntp.org
or it didn't exist when I 1st wrote the script.

: Let me expand on our pool.ntp.org experience. Right now it requires two 
: steps. The first is to do a DNS lookup on pool.ntp.org, craft a 
: configuration file with all 20 servers so revealed and then start up 
: NTP. After a few minutes NTP has found the best 3 or 4 servers and 
: continues with them. The next step is to whittle down the configuration 
: file to just those servers. Works gangbusters. Of course, the steps 
: could be automated with due incisions in the NTP source code. At the 
: moment, this is a little messy, since the configuration code is 
: smothered in weeds. It may even be possible to do these steps with a 
: script without changing the source code. Volunteers needed.

pool.ntp.org is the right way of doing things but I fear that
until the tools are ready, people will keep hitting the overloaded
stratum 1 servers when they don't need to.

For thouse that looked at the script, I have changed the wording
and Brad found bug which I haven't fixed yet.
It still lives here:
I do appreciate the feedback.


More information about the questions mailing list