NTP Pool Reaches 1000 Servers, Needs More

hgerstung writes "This weekend the NTP Pool Project reached the milestone of 1000 servers in the pool. That means that in less than two years the number of servers has doubled. This is happy news, but the 'time backbone' of the Internet, provided for free by volunteers operating NTP servers, requires still more servers in order to cope with the demand. Millions of users are synchronizing their PC's system clock from the pool and a number of popular Linux distributions are using the NTP pool servers as a time source in their default ntp configuration. If you have a static IP address and your PC is always connected to the Internet, please consider joining the pool. Bandwidth is not an issue and you will barely notice the extra load on your machine."

Comments

Free GPS time equipment!

[ask]

I must mention that right now by signing up for the pool now you also have a chance to get some really cool time keeping equipment. :-)

Re:load

[gregbaker]

Their servers can keep up just fine, or at least the one I run can. My stats show 1GB per month traffic and the ntpd process taking about 1 minute/day of processor time. That has been relatively constant over the year or so the server has been in the pool.

I think this is just a case of more==better. A bigger pool means more people can use their local zone instead of the global zone, the whole system can handle more clients, less load on servers means even more may be willing to join, ...

Seriously, it's not that big a deal. Just thow your server into the pool and forget about it.

Re:NTP Isn't Accurate

[ask]

Hi AC,

The NTP Pool monitors the servers and only uses those with accurate time. A server drifting several seconds off would be taken out of the pool until it got fixed.

Also, the NTP daemons are Quite Good at ignoring the servers with Bad Time Keeping.

Using ntpd with the pool servers will give you much much much more accurate time than trying to set it manually after looking at a web page.

    - ask

Re:huh?

[JackHoffman]

No, the network time protocol accounts for latency and eliminates its influence almost completely as long as the latency is roughly symmetric, which it usually is for small packets.

GPS time with OpenBSD

[ptudor]

If you grab a USB GPS receiver, I used a $60 BU-353, you can have accurate time easily.

openbsd# dmesg | tail -3
uplcom0 at uhub0 port 2
uplcom0: Prolific Technology Inc. USB-Serial Controller, rev
1.10/3.00, addr 2
ucom0 at uplcom0
openbsd# nmeaattach cuaU0
openbsd# sysctl -a | grep hw.sensors
hw.sensors.nmea0.timedelta0=-328.10115 9 secs (GPS), OK, Tue May 15 19:48:46.898
openbsd# echo "sensor nmea0" > /etc/ntpd.conf
openbsd# echo "listen on *" >> /etc/ntpd.conf
openbsd# ntpd -ds
ntp engine ready
sensor nmea0 added
sensor nmea0: offset 328.097637
set local clock to Tue May 15 19:57:46 PDT 2007 (offset 328.097637s)
sensor nmea0: offset 0.020612
...

Re:GPS time with OpenBSD

[ask]

Actually ... The USB latency can be pretty bad, so it's likely you'd get better time from a well-picked internet time server. You'd definitely get MUCH better time with a proper PPS (Pulse Per Second) time keeping GPS receiver or variations of that.

Re:GPS time with OpenBSD

[mrcaseyj]

In addition to the latency of USB, the nmea output of a GPS unit may not be very accurate. Go for a GPS with pulse per second if you can find one for a reasonable price. A while back I was checking the chipset specs for the cheap GPS receivers to find one with a pulse per second output. I found some but I forgot which ones they were. Of course you would have to open the case and do a little soldering. I'm not sure how you would hook it up to your server once you got the pulse per second out. I think maybe to one of the pins on the serial port that would trigger an interrupt.

Under OpenBSD I've gotten much more stable timekeeping by recompiling the generic kernel with only one simple change. I set the processor type to 586 or 686 as the case may be. Specifically in the /usr/src/sys/arch/i386/conf/GENERIC file I removed "option I486_CPU" and "option I686_CPU" so that it would be correctly configured for my pentium 166 cpu. I think the pentium has some time keeping functions the 386 and 486 didn't have. Although I haven't found the parts of the kernel code where this change does its magic.

Not so much the chips, but the timebase crystals..

[Ellis D. Tripp]

The component that actually determines the stability and accuracy of the real-time clock in your PC is the timebase crystal, not the RTC chip itself.

Like every other component in mass-market electronic gear, it is chosen with minimum cost as the primary consideration. Such "value engineering" also has done away with the tiny trimmer capacitor that used to be present on most motherboards, which could be used (along with a frequency counter) to tweak the oscillator frequency for better accuracy.

For real accuracy, the timebase oscillator needs to be kept at a constant temperature, which isn't possible in a PC that gets turned on and off. Ideally, the crystal (or the entire oscillator circuit) is enclosed in a package equipped with a heater element and temperature sensor, and kept at a constant temperature. Such a circuit is called an OCXO, or Oven Compensated Crystal Oscillator, and is standard equipment on laboratory grade equipment like frequency counters and signal generators.

Re:huh?

[mrcaseyj]

"Bandwidth is not an issue and you will barely notice the extra load on your machine."

If that is the case, why do they need more servers?

If I understand it right bandwidth isn't an issue because they can tailor how much of the pool load goes to your machine. When someone queries the pool their ntp client does a DNS query to pool.ntp.org. The pool's DNS server semi randomly returns the IP address of one of the volunteer servers in the pool. If you tell the pool operators that you have only a little bandwidth then the pool DNS server will only return your IP address say one tenth as often as it does the IPs for the high traffic servers. This allows you to decide how much load you're willing to bear. Even if the pool is overloaded, your machine doesn't have to be.

Re:Google

[hgerstung]

Well, unfortunately DynDNS will not work here, simply because the clients will resolve the IP address once at startup and then stick to it (it will not be re-resolved later). The NTP Project is working on that, but currently there is no chance to use DynDNS or even "pretty static" IPs ... Heiko

Re:NTP Isn't Accurate

[SnowZero]

You do realize all those times are in milliseconds, right? So, the largest difference between your computer and one of the servers is 27 milliseconds, and the leading "-" in front of the hostname means it isn't even being used for synchronization. Also, either you didn't let it settle for a while, or your local computer clock is inaccurate, because you are still polling once a minute. A "healthy" computer clock will lower the poll frequency significantly if the local and estimated net clocks don't jitter much. I did have one machine with a clock that just sucked, so I had to make sure it was a client of another machine which could act as the timekeeper on my home network, and make sure it polled the timekeeper often.

Personally, I don't use the pool, and instead find some stable servers near to my ISP. But you really can't argue against the NTP pool as a default setup, since it works everywhere. So, if it bothers you, find some closer servers or convince your ISP to run a time server (many are already doing so). In both cities I've lived in, I was able to find an open stratum-1 server with a ~20ms delay (Thank you GPS).