Free Clock Democratizes Atomic Accuracy 178
schliz writes "A new, trial network of software-based clocks could give data centers and networks the accuracy of an atomic clock for free. The so-called RADclock analyses information from multiple computers across the internet by collecting the time from each machine's internal quartz clock, the time it takes for this information to be transmitted across the network, and comparing all the information collected to determine a time that is most likely to be accurate, so machines are calibrated across the network with up to microsecond accuracy — as good as that provided by a $50,000 atomic clock, researchers say."
Re:A solution in need of a problem? (Score:3, Informative)
NTP solved this ages ago by distributing atomic clock accuracy through the network.
The only problem this will solve is where it is a private network not connected to public NTP servers (or organizations that do not trust public NTP). In that case, they would most likely be able to afford a atomic clock.
An alternate would be radio clock signals like the old MSF Rugby signal in the UK (now moved to scotland)?
Ok not as accurate as an atomic clock but for most NTP cases it would be accurate enough
Re:A solution in need of a problem? (Score:3, Informative)
From TFA:
"The RADclock project (formerly known under 'TSCclock') aims to provide a new system for network timing within two years. We are developing replacements for NTP clients and servers based on new principles, in particular the need to distinguish between difference clocks and absolute clocks. The term RADclock, 'Robust Absolute and Difference Clock', stems from this. The RADclock difference clock, for example, can measure RTTs to under a microsecond, even if connectively to the time server is lost for over a week! "
ymmv
It solves one problem (Score:5, Informative)
The Financial Sector.
Also, synchronized robotics, precisely coordinated CNC, and a host of other applications. Primarily, it's where absolute time isn't the concern, but rather where arbitrary time must be consistent between multiple devices (accounting for propagation delays, failures, etc...). Of course, protocols like PTP solve this fairly neatly: this particular product solves a different problem, and probably isn't actually useful.
There are two time issues to consider. One is how close your environment is to true time. The other is how close your individual devices are to one another. Messaging time-critical information between devices is severely complicated when the two devices are not on the same plane time-wise. Atomic clocks and the like solve the first problem. PTP solves the second problem. NTP almost (95%) solves both, but falls short in certain extremely time-critical situations.
Re:A new low in editorial savvy (Score:4, Informative)
Could you have done a google search yourself or something?
Then you might find this [unimelb.edu.au]:
The RADclock project (formerly known under 'TSCclock') aims to provide a new system for network timing within two years. We are developing replacements for NTP clients and servers based on new principles, in particular the need to distinguish between difference clocks and absolute clocks. The term RADclock, 'Robust Absolute and Difference Clock', stems from this. The RADclock difference clock, for example, can measure RTTs to under a microsecond, even if connectively to the time server is lost for over a week!
Re:Use GPS (Score:5, Informative)
If it's off by a known amount, I'd expect you could calculate the real value with some kind of mathematical equation.
Re:A solution in need of a problem? (Score:4, Informative)
GPS also provides an extremely accurate clock signal all around the world (after all, it comes from an atomic clock onboard the satellites). All you need is a GPS receiver. You can put most decent GPS modules into a "clock mode" where you lock their position on the globe and they optimize the calculations to give you the most accurate time.
Re:Nano not micro (Score:5, Informative)
Re:Use GPS (Score:3, Informative)
- 12 seconds
The problem is that this will rise when the next leap second is scheduled. When GPS started, GPS Time was identical to UTC. And leap seconds aren't based on a regular pattern but on the irregulatories of earths movement.
So it's good enough for relative time or within a system that agreed to use GPS time instead of UTC. Any other setup would require constant manual intervention. (at least minitoring of International Earth Rotation and Reference Systems Services announcments)
http://en.wikipedia.org/wiki/Leap_second [wikipedia.org]
Re:Nano not micro (Score:3, Informative)
It's called NTP. You just have to be careful who you choose as your peers.
Re:A solution in need of a problem? (Score:5, Informative)
Re:Computer Clock resolution? (Score:4, Informative)
That's right. Also, PC clocks tend to be not that great, in terms of reliability of the frequency, and error such as clock drift.
Hence the general recommendation to use NTP to keep your clock in synch with a good time source; a good time source, being something such as an atomic clock, or a radio-based receiver that provides time from a good source.
A PC clock can easily have errors of 100 PPM or higher. Or ~10 seconds of drift per day
Factors that seem small such as temperature can effect the frequency of the clock crystal also
Re:A solution in need of a problem? (Score:3, Informative)
Meinberg makes a line of products that provide GPS backed NTP servers, as well as PCI/PCI-E cards that give PC's a GPS based clock (with an external antenna). They also make a pretty good NTP server/client for WIndows. It's overkill for most projects, but if you have a large datacenter or need for very accurate time, I would think they could be useful, if nothing else to keep you from having to rely on external time sources (which could be a potential security hole). This research seem more about making an improved and more accurate version of NTP, which is nice I guess, but NTP is already pretty accurate (on a scale of what is actually needed for 99.99% of situations).
Re:Use GPS (Score:5, Informative)
leap seconds Re:Use GPS (Score:1, Informative)
Bleah.. you don't know much about GPS timing, do you?
The message that the GPS satellite sends *includes the offset from UTC* including the number of leapseconds.
GPS time can't have leap seconds because it needs to be monotonic and continuous, like TAI time. UTC needs to line up with the Earth's rotation, so they need leap seconds.
Time arithmetic on GPS time is straightforward. Not so with UTC.
Re:A solution in need of a problem? (Score:5, Informative)
The next generation protocol has already been invented too, the Precision Time Protocol [wikipedia.org] (PTP) recorded as IEEE 1588, with open source implementations [sourceforge.net] already available.
PTP isn't a replacement to NTP: it's trying to solve a different problem. It's not useful on a general company LAN, but rather on a network that controls robotics or measurement devices.
Some limitations of PTP:
* only one "grandmaster" clock, i.e., no redundancy
* no WAN connectivity; it's UDP multicast-only, and so not very routable
* no security/signing of timestamps; NTP has security extensions if you need to be able to trust the time
* patented by HP/Agilent; NTP is both open and free
http://www.meinberg.de/download/docs/ieee1588/meinberg_ieee1588_conference2005_whitepaper.pdf
PTP was designed for small subnets of systems where measurement instruments and robotic systems are running on. This isn't a general PC/server solution.
Re:A solution in need of a problem? (Score:2, Informative)
PTP is NOT an Internet-ready solution. It only works modestly reliably on systems where you have exceedingly predictable latencies. Like inside a dedicated time sync LAN, or using high quality links between sites. (go buy some dark fiber!) Things like having load on a shared LAN link will throw off the results. PtPv1 was hideously allergic to even slight variations. PtPv2 added some buffering/averaging, but didn't change the basic problems.
Re:Nano not micro (Score:3, Informative)
NTP is unreliable even on good networks and hopeless on even mildly bad networks. NTP's time synchronization can't be relied on to be better than 1ms, nowhere near the precision of an actual atomic clock.
RADclock can do much better.
Re:A solution in need of a problem? (Score:3, Informative)
If you really want to know, check out the rationale of the folks building Linux clusters with Myrinet instead of Ethernet. Here's a link to a paper discussing one implementation from 2001: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.9270 [psu.edu]
Simply put, when working with high performance computing tasks using parallel toolkits like MPI or on problems that require inter node communication of intermediate results, latency really matters to performance. Minimum latency of Myrinet or similar communications frameworks is a small fraction of what ethernet's latency is.
So to answer your implied assertion, ethernet does not work perfectly well unless you consider "well" to cover the case where running a program takes 10x longer than it otherwise would for certain problems, IE the above mentioned timing-critical ones....
Re:Uhmmmm (Score:3, Informative)
Admiral walks past clock shop, sets watch to grandfather clock, goes to naval base and fires cannon.
After the Admiral walks past the clock shop, the clockmaker shows up for work. He waits until the cannon is fired and then corrects the grandfather clock.
The admiral is setting his watch to the "corrected" time from yesterday.
The only thing that's off is that the correction that the grandfather clock gets would be fairly minor, as the assumption is the cannon is fired soon after he sets his watch.
But it could be that his pocket watch is REALLY inaccurate and the grandfather clock less so.
Re:Use GPS (Score:1, Informative)
Or, you know, use the UTC offset as broadcast by the GPS system... http://en.wikipedia.org/wiki/GPS_time#Timekeeping
Re:A solution in need of a problem? (Score:3, Informative)
Every GPS unit is capable of receiving the time, including those in phones (it's part of the calculation to obtain position), and as far as I know even cellphone-based GPS receivers internally use NMEA. For precise to-the-microsecond time, though, you need one with a 1PPS output (a 1Hz squarewave that transitions precisely at each second), as the NMEA data will have some delay due to the serial protocol in use. NMEA alone will probably give you accuracy down to a few milliseconds.