Slashdot Mirror
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."
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. :-)
--
ask bjoern hansen
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.
latency. The time you get back from the NTP server is the time the server sent the request. The client has to count the time it took to get a response and use that as a fudge factor. More servers means your client can find a closer server and minimize the transport time.
Do you even lift?
These aren't the 'roids you're looking for.
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
--
ask bjoern hansen
Please name one ntp server in the pool that it off by more than .5 seconds? The vast majority are accurate to under .1 seconds. I do not believe that the AC who said these aren't accurate understands how NTP works.
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
Hi Nuintari,
Yes - it'd be great if more ISPs offered time keeping services.
One of the plans for the pool is to let ISPs sign up their address space and tell where their NTP servers are. Then when a user using the pool asks for time servers we can point them to the local servers (if they are keeping proper time, etc etc). But it's a bit down the todo list, mostly due to lack of interests from ISPs.
- ask
--
ask bjoern hansen
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.
Your google fu sucks, grasshopper.
NTP abuse
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
Google's server farms are distributed around the world. both coasts and in between as well as Ireland, Belgium and elsewhere.
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.
Remember "News for Nerds, Stuff that Matters"? Help make it a reality again! http://soylentnews.org
The virtualized servers don't usually keep their own time - or when they do they do a poor job.
--
ask bjoern hansen
Uh... how exactly do you propose they work with dynamic IPs?
All organizations interested in possibly hosting a NIST Internet Time Service server are invited to contact Time and Frequency Division Chief Thomas O'Brian for more information, including a description of the equipment that the organization must have available and a discussion of the other technical qualifications necessary to host a server: obrian@boulder.nist.gov .
Edward Burr
Having a smoking section in a restaurant is like having a peeing section in a swimming pool.
USB latency is generally too high for this.
Not a sentence!
For those interested, you can change your Windows time servers to NTP servers in the registry here: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Cur rentVersion\DateTime\Servers]
You want fun, go home and buy a monkey!
Of course they do. Anyone who has ever setup ntpd should know that quite well. The default/example config file is STREWN with examples of using hardware clocks... So much so it's difficult to figure out how to set it up to sync to other servers via the network.
From the man page:
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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
A few thoughts...
:)
Unlike a partnership with Akamai, there's no compelling monetary reason for an ISP to offer their own NTP server. Therefore, the easiest (least costly) solution -- at the ISP end -- is probably the most likely to win. Adding a line to dhcpd.conf is probably easier than configuring BIND to issue lies.
And while not everyone uses DHCP, they certainly have some mechanism for communicating things like DNS server addresses, default gateways, and so on. Using that same mechanism (be it DHCP, bootp, or snail mail) to inform the customer of the local NTP server seems trivial in every instance I can think of.
Clients that don't care will obviously ignore this data, but customers who do care can modify their client software accordingly.
Eventually (as in, within the MTBF of a Linksys router), if it ever gains any foothold, clients will use this data by default.
But I guess the most glaring problem to me is that, surprisingly often, the ISP's own DNS servers are slow and/or broken, and overridden. Much of Roadrunner's network is, for instance, assigned DNS servers which are so slow that when browsing the web, more time is spent on simple DNS lookups than on downloading and rendering content.
This, in turn, causes people like me to use a different DNS server on a different network. In my case, I use Level3's DNS at 4.2.2.1 because it is easy to remember and quite fast. Your suggestion ties together DNS and NTP inextricably, such that I'd also be using L3's NTP server by default, when all I really wanted was different DNS.
I don't want a solution to one network problem to have cascading effects on other network services. There's enough of that in the world already.
Remember, the whole point of this is to eliminate end-user manual NTP client configuration, and reduce network load, while offering the useful service of providing accurate time. And I can only hope that, after all of this, network-attached devices of all types will use this mechanism (whatever it is) to automatically derive time from a nearby NTP server.
Some of these devices will be reconfigurable to use whatever NTP server the user wants (certainly, my Linux box is), but hopefully some simpler devices will not be (think print server, networked DVR, WiFi LCD picture frame, or other minimally-configured box).
If a standard method for propogating NTP server names to end-users ever does get implemented, I shouldn't have to run a local copy of BIND and my own regimine of poison, just to allow independant settings for both DNS and NTP servers.
But that's all just my opinion. It is probably wrong.
Kid-proof tablet..
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).
NTP servers are written around precise clocks and with minumum processing latency in mind.
An NTP server running on a Windows platform already is significantly worse than one on Unix/Linux, and I think that should not be further degraded by running it in a virtual machine.
Remember you want to put the current local time down to nanoseconds in the reply packet. Your underlying platform should be capable of providing that time, and the processing code should not take so long that the time value is completely meaningless.
When you don't trust the program and don't want to put up a dedicated machine with no other critical stuff on it, then it is better to just forget about it.
Well, the concept is this:
You can have five billion machines all hitting a single "atomic clock". Or you could have a few servers hit it and hundreds of servers that sync up with *those* servers. Seriously, even in cases where all machines of an organization or university or corporation sync off one single internal NTP server (which itself them hits one of the servers in this pool, I'd presume) -- you're still talking about billions of machines that need to have the proper time synced on a daily bases across the globe.
I mean . . . you don't have just one single DNS server for the entire planet, because adding more would just raise inaccuracies... you have DNS servers all over the planet to serve various geographies and balance the load.
Life is wet, then you dry.
http://www.timetools.co.uk/
They are a lot more than $20. Now I am just waiting for the customer to
provide another hole in the roof so we can get our GPS antenna outside.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein