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."
Nano not micro (Score:2)
Real atomic clocks often have only have a nanosecond error. And new ones using ion gates are promising mobile clocks that are even more accurate. This is still pretty cool
Re: (Score:2)
What's a few nanoseconds among friends? :p
Computer Clock resolution? (Score:2, Insightful)
What is the resolution of the built-in clock on most PCs? An Atomic clock might have nanoscale resolution, but if a computer's clock only has microsecond resolution, then it stands to reason that you can only synch the computer to within 1 microsecond of accuracy, no?
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: (Score:2)
With an error rate that high, it doesn't even sound worthwhile to sync with anything less than millisecond accuracy. Even if you sync exactly, you can't maintain accuracy long enough to reliably base any high-precision timing tasks on the internal clock.
Re: (Score:3, Interesting)
These guys aren't using the PC clock crystal, and they're improving on NTP by a large margin.
Plus they split interval and wall-clock timers for people who really care that their interval measurements don't get screwed with by leap second (or DST) resets and such, and the accuracy of those measurements is down in the ns range.
Re:Computer Clock resolution? (Score:5, Interesting)
if a computer's clock only has microsecond resolution, then it stands to reason that you can only synch the computer to within 1 microsecond of accuracy, no?
No. You can sync up to fractions of a clock cycle fairly easily. On average you can only report the time at any instant with around 0.5 uS accuracy, but you can set the edge where it cuts over from one uS to the next as accurately as you want, given enough time to sync...
Slashdot car analogy is I change my oil 4 times a year, so you're saying I can't tell you when I change my oil with any accuracy higher than a whopping 3 months. Yet I assure you, if sufficiently motivated, I can "sync up" such that I change the oil precisely at midnight on the 1st of every third month, with a reportable accuracy of like an hour or so.
Re: (Score:2)
I'm sure you mean to say that for every discrete interval n we can only report the value accurately +/- (n/2)
In this case n being 12/4 = 3 months, I can tell you when you change your oil with 1.5 month accuracy.
Also, for the car analogy, you would have to not make any excuses for missing your oil change, including weekends, sickness, or your oil change place being closed at midnight. I will accept +/- 1 hour.
Re: (Score:2, Interesting)
I don't think it's anything special.
If you want atomic clock accuracy, then you go fetch the time from an actual atomic clock. Even back in the 1980s, I had a Commodore Amiga program that would automagically dial a 1-800 number, fetch the time, and set my internal clock. Doing it today via the web should be a piece of cake.
Re:Nano not micro (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Are you sure it's really syncing? How often? (I'm sitting here with my laptop and cell phone disagreeing on time by more than a minute, which is annoying because the laptop is supposed to be syncing time to something accurate...)
Re: (Score:3, Informative)
It's called NTP. You just have to be careful who you choose as your peers.
Re: (Score:2)
ntpd also corrects for clock drift if the kernel supports it.
Re: (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.
RTFA - it talks about NTP already (Score:2)
"Fetching the time via the web" is using NTP or SNTP to get time from better clocks. The article says that NTP is at best getting you millisecond accuracy, and claims RADclock can get to microsecond level.
A solution in need of a problem? (Score:5, Insightful)
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.
Re: (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: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: (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
Re: (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.
Re: (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
Re: (Score:2)
or example, can measure RTTs to under a microsecond, even if connectively to the time server is lost for over a week!
Let's see... with connectivity loss over a week, that makes around a 604800000000us RTT plus or minus some error. If you don't trust your clock, and it's important to you, why would you leave it without connectivity for over a week?
Re: (Score:2)
Its gone thru a pretty severe journalist / PR filter.
"RTT under a microsecond" doesn't mean TCP RTT, it means the "delay" column on the equivalent of the peers command in the ntpq program for this new thing displays more than 3 decimals of milliseconds.
And the connectivity lost over a week means the "poll" interval column on the equivalent of the peers command in the ntpq program can go in excess of a week,
For example, I'm syncing to several clocks at home, one of which is ntp.sixxs.net. My delay is 130.76
Re:A solution in need of a problem? (Score:4, Insightful)
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.
If one reads the explanation at the beginning of the article literally (as the person who wrote the summary did), the article does seem to say that this system averages the time from the cheap quartz crystal clocks in all of the computers in order to arrive at a highly accurate estimate of the true time of day. This of course is absurd. If all of the clocks start out between one and five minutes fast, they will converge on a time that is about three minutes fast. So much for microsecond accuracy!
The article suggests that NTP did indeed solve this problem. Reading between the lines I gather that these researchers are developing the next generation protocol to replace NTP. This will allow all of the nodes to synchronize more tightly with whatever time source (such as an atomic clock) is used.
Re:A solution in need of a problem? (Score:5, Informative)
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: (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: (Score:2)
Re: (Score:3, Interesting)
To answer your implication about time variation between nodes, even a basic ntp server to which your local network nodes sync will keep them in at the same wall clock time, even more so if you follow the protocol and use multiple servers, even if the time source is the servers' quartz clocks. If you have more than a few milliseconds skew after that, y
Re: (Score:2)
If you need more than fractional second timing for syncing a process or physical events, you don't try to coordinate timing over a communications medium without guaranteed latency (like ethernet). This can be seen in certain types of linux superclusters that abandon ethernet and its descendents in favor of synchronous communications.
Why would you go for a expensive synchronous networking when ethernet works perfectly well, given non-broken software?
Re: (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 com
Re: (Score:2)
the need for crazy expensive accurate timing devices, the time it takes to fine tune them and some crazy ass person (like myself) with a fetish for time keeping to stay on top of it. Instead of buying ridiculously expensive time keeping appliances
Thats a heck of a lot of effort and money to get around opening port 123 on the firewall. Or implementing a "layer 7 firewall machine" that runs nothing but ntp, with one leg in the private net and one on the public internet.
Also in the olden days, like a decade or two ago, I was brought up that GPS units / radio clocks in general cost tens of thousands of dollars. Not so much anymore.
Re: (Score:2)
This really sounds to me like an interesting experiment in error correction.
You have n machines which were all (or most) at some point within 1 ms or so sync to an atomic clock. They all immediately started to add error to that time. So now, this system seems to be, sampling all of these machines, collecting all of their skew together. If the skew is random, you would expect it to cancel itself out. If it tends to bias in one direction, you should be able to figure out an average skew.
Then that average is u
Re: (Score:2)
NTP solved this ages ago by distributing atomic clock accuracy through the network.
Wrong. NTP is rarely as good as a millisecond. Atomic clocks should be accurate to better than a microsecond.
There is an IETF effort, TicToc [ietf.org], intended to help improve time transfer to better than NTP accuracy, but that requires router assistance (i.e., participation by the ISP), as routers and switches will introduce large and indeterminate delays by atomic clock standards.
Re:A solution in need of a problem? (Score:4, Funny)
You probably missed the point that the project is based in Australia. NTP doesn't work down there, because the Coriolis effect makes Australian clocks turn the opposite way of clocks in the Northern Hemisphere, just like their toilets swirl the other direction. This creates a problem, since many distros have NTP enabled by default, which causes the system clock to run backwards on Australian computers - really makes a mess of the logs, screensavers activate an hour before the computer is turned on, all sorts of odd things. If you start looking at the RADclock code, you'll find that it's surprisingly simple and elegant - they simply reverse the byte order of the NTP messages, and - voila! - their clocks can now run forwards while remaining synchronized.
This explanation brought to you by a six-pack of Fosters.
Most probable time... (Score:5, Funny)
I can imagine the speaking clock:
"At the third stroke, it will be, most likely, sixish"
Use GPS (Score:2, Insightful)
They have atomic clocks on board and GPS receivers therefore give highly accurate time.
Re:Use GPS (Score:4, Interesting)
A GPS receiver will be useless as the GPS time currently is (IIRC) 12 seconds ahaed of UTC.
GPS doesn't honor leap seconds. This behaviour is by design as it's quite hard to halt the sattelites orbits for a second.
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: (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.or [wikipedia.org]
Re: (Score:2, Interesting)
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.
Easy way round this if you can access ntp but need the accuracy of gps:
Assume ntp is accuracte to within 0.5s (oviously it's much more accurate). Take the difference between ntp and gps times and round to nearest second. This gives you the current number of leap seconds, and you can then adjust your gps time with no manual intervention.
Re: (Score:3, Insightful)
Surely you're not suggesting that keeping accurate time with an atomic clock doesn't require manual intervention every time a leap second is introduced?
Re: (Score:3, Insightful)
Yes, you could, but what about the next leap second that changes it to 13 seconds (or worse, 11).
If you wanted to keep your UTC accurate, you'd have to ensure you kept patching your software each time another was announced. Not the end of the universe by itself.
But then, you've also got to deal with the problem of overlapping time (1/1/2015 12:00:00.5 happening twice), which for most people isn't an issue, but if you've got an application for which microseconds are important (like the high-volume financial
Re: (Score:2)
Well, you could separate the distribution mechanism for time data vs correction data.
The corrections can be high-latency and knowing what the latency is doesn't matter at all. The time data needs to have known latency, and preferably low latency.
Software updates are just a very-high-latency mechanism for distributing this information. It would not be difficult to come up with a better approach. WAAS already operates under a similar concept - providing additional metadata useful in increasing the accuracy
Re: (Score:2)
OK, you got me on semantics there.
"If you wanted to keep your UTC accurate, you'd have to ensure you kept updating your software configuration each time another was announced."
Better? Still requires manual intervention.
Re: (Score:3, Interesting)
YRW, it's behind, not ahead.
And that's why you have /usr/share/zoneinfo/right hierarchy anyhow:
Re: (Score:2)
The GPS gives you a highly stable timebase for peanuts, and then you can
Re: (Score:2)
If you have some pathological need to have the exact wall clock time down to the microsecond (an amount of time no human can distinguish) correct and identical at multiple discrete
Re: (Score:2)
While computers have significant issues with subtraction, I am positive someone can find a solution to this monumental problem. After all the algorithm, while clearly complex seems solvable if only networked computers could connect to some remote resource to discover new information occasionally. Or perhaps these computing devices could respond to some sort of human interaction to gather such information and respond in a well defined manor.
Re: (Score:2)
While computers have significant issues with subtraction, I am positive someone can find a solution to this monumental problem. After all the algorithm, while clearly complex seems solvable if only networked computers could connect to some remote resource to discover new information occasionally.
Well.. it's called NTP.
Re:Use GPS (Score:5, Informative)
Re: (Score:2)
Yeah. I read it up a few minutes after posting...
i stand corrected.
Re: (Score:2)
Re: (Score:2)
There are two considerations here that many people don't realize are separate.
Frequency
Time
GPS provides Stratum 1 level clock. Time is usually done via NTP and then kept accurate by your stratum 1 frequency clock.
Also, the position of the satellite is meaningless for issues of timing, it only affects geolocation.
Re: (Score:2)
Re: (Score:2)
Good luck getting a GPS receiver on the roof of an existing facility. Running conduit, grounding, waterproofing, etc. People say "hey, the Garmin GPS 18x costs only $100", but it will require ten months and $5K to install.
If you wanted to mount a GPS receiver on the roof of a building and wanted to use something off the shelf, perhaps you would be better off looking at the Garmin marine offerings. The GPS 17x has the same timing accuracy of the 18x, has the same MSRP, yet is packaged in a weatherproof housing designed to be mounted on a boat or a pole and survive the harsh conditions of the open ocean for many years.
Forgive my ignorance... (Score:3, Insightful)
...but in what situation would the time of day on a server or cluster need to be accurate down to a microsecond? Military, I would presume...but what else?
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: (Score:2)
Cool! Thanks for the mini-lesson :-)
Re: (Score:2)
Of course, the multi-device coordination problem is better solved by communications between the devices (ready to do step 1, do step 1, doing step , done step 1, ready to go to step 2, etc). Think of the transactional model (begin transaction, do work, commit transaction, wait for ack).
The only problem with that is latency - if you want two devices to coordinate steps while moving from step to step in less time than it takes for packets to travel between them, then you need synchronized clocks.
Re:why accurate down to a microsecond? (Score:2)
Re: (Score:2)
A new low in editorial savvy (Score:2, Insightful)
I'm also pretty sure there are desktop clocks based on microcontrollers that implement ntp, so they display an accurate time without a computer.
Most data centers that really care about time nowadays install a commonly available GPS unit on site, which syncs clock time with all the atomic clocks in the flying GPS constellation.
Seriously, could the edi
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: (Score:3, Funny)
Damn 2 years?? I suspect the time is somewhere between 2009 and 2011...
Re: (Score:3, Interesting)
- Reduce the potential points of failure from one single bottleneck to infinite peers.
- Require no configuration (some old routers for
Re: (Score:2)
Re: (Score:2)
But even the outside scenario of a time synchronizing s
Re: (Score:3)
I'm gonna go out on a limb and say this is not a big deal.
Re: (Score:2)
Re: (Score:2)
NTP works fine without central servers, by the way. You just sync between machines on your site, which solves 99% of the problems you wanted time sync for in the first place.
This is the sort of story item that I would expect to see in one of the little side news boxes... like announcement of a new release on freshmeat including the new algorithm, or maybe a summary of news from the ntp world on a network time dedicated
Re: (Score:2)
NTP works fine without central servers, by the way. You just sync between machines on your site, which solves 99% of the problems you wanted time sync for in the first place.
Only if you don't really care about time in the first place. NTP is likely to go on a wild goose chase once in a while and then reset time to recover.
Re: (Score:2)
Re: (Score:3, Interesting)
the trick is within a given site it does not matter ~95% of the time if there is a time skew if The Whole Site is wrong by the same amount. So if the error is exactly 5 minutes 14.507693 seconds and the whole site has that same error then everything works out.
In the other ~5% of the time having a few systems sync to say our friends tick|tock.unso.nay.mil (or another NTP server) sorts things out nicely.
Re: (Score:2)
You can't realistically put a GPS receiver into every server; you'd be lucky if the top server managed to get any signal and the rest sure won't. Antenna cabling would be impossible with 40+ servers per rack.
Re: (Score:2)
Nearly no one does that. Two or three servers per site (depending on redundancy needs) is fine for all the sites I've seen.. use ntp to sync over local lan to those time servers.
Or if you really care about time that much, do go ahead and put a receiver in each server. Share antennas if needed. It's not impossible for those few applications that *really* need accurate time and who aren't for some odd reason interconnected using a common clock pulse over a dedicated network.
Uhmmmm (Score:2)
Say I have 1000 PC's at my place of work and a certain percentage are usually a little fast (clock wise) while another percentage are usually a little slow.
If I use the average of all clocks to determine the "actual" time, wouldn't it slowly shift either to the slow side, or the fast side over time?
Say 550 of those 1000 are usually a second slow per day. That is a bias towards slow every time we take an average. We sync all clocks to the slow side and keep on repeating this. The longer you do this, the w
Re:Uhmmmm (Score:5, Funny)
This reminds me of an old joke about a retired Admiral who is responsible for sounding the morning cannon at the naval base, walking past a watchmaker's shop every morning and setting his pocketwatch to the correct time from a reliable old grandfather clock in the store window.
One day, on the walk in, he happens to see the watchmaker cleaning the store windows and mentions how he finds it amazing that the old grandfather clock keeps such flawless time.
"Oh, that old thing?" says the watchmaker. "It drifts horribly, and I have to reset it almost daily."
The Admiral then asks, "Since I've always noticed that it's reliable, from where do you get the time to set it?"
The watchmaker replied, "I use the report from the morning cannon at the naval base. It's always right on time."
Re: (Score:2)
Unfortunately, that joke doesn't actually work, since each of them is using the other's time reference before they generate their own. The watchmaker would have to reset the grandfather clock BEFORE he saw the admiral, which would be before the cannon sounded, so it wouldn't work.
Nice try, though.
Re: (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 coul
Favorite Quote (Score:4, Funny)
One of my favorite quotes relates to this;
Credit goes to Mark Twain (IIRC).
"When you have a watch/clock you always know what time it is. When you have 2 you are never quite sure."
Re: (Score:2, Interesting)
The idea sounds good on paper (Score:2)
Can't wait to see all computers set their clocks to January 1st, 1980.
Segal's Law (Score:2)
Re: (Score:2)
At last (Score:2)
This reminds me of the Swiss watchmaker (Score:2)
One day the watchmaker happened to be out in the street at noon, and he mentioned this to the office worker. "That's funny", said the worker, "I always set my watch when I w
rogue/malicious clocks (Score:2)
How does this account for rogue or malicious clocks present on the network? It sounds like it would be pretty easy to introduce significant error into the system.
I think I'll keep using one system connecting to the atomic clock and all the rest connecting to that one to keep their time accurate.
This is a simple case of NTP envy (Score:2)
The people behind this project tried to get the ntp hackers interested a year or two ago, but since the only thing they have is a possibly improved distributed algorithm, vs real NTP which has been designed to work even in the face of (intentional or accidental) falsetickers, nobody was very interested.
Any NTP wrangler who's the least interested in accurate local clocks will spend an hour and less than $100 to buy a cheap gps (Garmin GPS18(x) LVC) with Pulse Per Second (pps) output, a USB cable and a 9-pin
Re: (Score:2)
That's all well and good, but it gets time to one server. Now what to do about the other 40 servers in the rack?
And don't say NTPd, because that will not get you anywhere close to microsecond accuracy. If it doesn't lose sync completely for no reason.
Chrony is somewhat better, but it's still stuck with the NTP protocol.
Re: (Score:2)
If you need us precision for all 40 servers in a rack, the solution can be either very simple (and cheap) or very complicated (or even cpu-intensive):
The obvious solution is to make a small amplifier, so that the PPS signal can be split into 40 cables and spread to all the servers.
Since NMEA is a one-way protocol you can also wire up one server which can send commands to the GPS and let all 40 of them listen to the responses.
You only need RMC or GGA output in order to number the second pules on the PPS sign
100 Comments and No Cospiracy Theory yet! (Score:2)
There was a story a few years back about a Security researcher that determined the quartz units in every computer are unique and have different enough time drift to fingerprint the individual machine's traffic despite IP address changes, proxies or anything similar. Botnets attacks wouldn't be tracked back to them, but CNC traffic to the botnets should still work.
Anyways this software comes out and samples millisecond differences between computer clocks on large networks, put this together with that guys Th
Voting on truth? (Score:2)
This sounds like a Wikipedia approach to "truth"... you have enough people voting on it and sooner or later you have something that sort of resembles and might actually be truth. Or in this case, accuracy.
I would think there would be much better ways than this of obtaining accuracy. One of the basic problems with any voting scheme is that you can get a large amount of drift as it is assumed there is no standard other than concensus. NTP is a reference because there is are systems out there that are known
precision, accuracy... who cares (Score:3, Insightful)
Let's just not pay attention to things like the difference between precision and accuracy anymore, it's too much work.
I mean, there's no way that the same physical limitations would apply to all quartz clocks, right?
Re: (Score:2)
I think you've been had.
Re: (Score:3, Funny)
That reminds me, just where exactly did you get that sarcasm detector?
Re: (Score:2)
Re: (Score:3, Funny)
You know what they say. When life gives you unclaimed nuclear material, you get busy creating superheroes.
Re: (Score:2)