NTP Pool Reaches 1000 Servers, Needs More 230
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."
Free GPS time equipment! (Score:4, Informative)
Re:load (Score:5, Informative)
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:huh? (Score:3, Informative)
Re:NTP Isn't Accurate (Score:5, Informative)
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:NTP Isn't Accurate (Score:3, Informative)
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.
Re:Better way To Do This (Score:2, Informative)
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
Re:huh? (Score:5, Informative)
GPS time with OpenBSD (Score:5, Informative)
Re:GPS time with OpenBSD (Score:5, Informative)
Re:Unless netgear hears about you (Score:2, Informative)
NTP abuse [wikipedia.org]
Re:Google (Score:3, Informative)
Re:Google (Score:3, Informative)
Not so much the chips, but the timebase crystals.. (Score:5, Informative)
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:VMWare? (Score:2, Informative)
Re:Google (Score:1, Informative)
Re:Better way To Do This (Score:4, Informative)
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 .
Re:GPS time with OpenBSD (Score:5, Informative)
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
Re:atomic clock to PC connection? (Score:3, Informative)
Re:huh? (Score:5, Informative)
Windows Time (Score:3, Informative)
Re:atomic clock to PC connection? (Score:3, Informative)
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:
Re:GPS time with OpenBSD (Score:3, Informative)
Re:Google (Score:5, Informative)
Re:Better way To Do This (Score:4, Informative)
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.
Re:NTP Isn't Accurate (Score:5, Informative)
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).
Re:security (Score:2, Informative)
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.
Re:Google (Score:3, Informative)
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.
Undo moderation (Score:2, Informative)
We bought one from these guys. (Score:3, Informative)
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.