Forgot your password?
typodupeerror
IT

Free Clock Democratizes Atomic Accuracy 178

Posted by samzenpus
from the free-time dept.
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."
This discussion has been archived. No new comments can be posted.

Free Clock Democratizes Atomic Accuracy

Comments Filter:
  • 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

    • by jgagnon (1663075)

      What's a few nanoseconds among friends? :p

    • 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?

      • by mysidia (191772) on Thursday July 08, 2010 @09:33AM (#32838842)

        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

        • 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)

          by jthill (303417)

          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.

      • by vlm (69642) on Thursday July 08, 2010 @09:51AM (#32839154)

        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.

        • by b4dc0d3r (1268512)

          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)

        by bunratty (545641) on Thursday July 08, 2010 @09:24AM (#32838742)
        NTP [wikipedia.org] has been around for decades. Even Windows phones home for the time every so often.
        • WHy is it that even though I'm set to sync with NTP, my computer time will vary by minutes, even after a month or two? Its really shocking that my computer is this terrible at keeping time.
          • 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)

        by jimicus (737525)

        It's called NTP. You just have to be careful who you choose as your peers.

        • by Guspaz (556486)

          ntpd also corrects for clock drift if the kernel supports it.

        • Re: (Score:3, Informative)

          by amorsen (7485)

          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.

      • "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.

  • by iserlohn (49556) on Thursday July 08, 2010 @08:48AM (#32838238) Homepage

    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)

      by EricTheRed (5613)

      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

      • by marcansoft (727665) <hector@mar c a nsoft.com> on Thursday July 08, 2010 @09:15AM (#32838612) Homepage

        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)

          by Kaboom13 (235759)

          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)

      by Sub Zero 992 (947972)

      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

      • by Idbar (1034346)

        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?

        • by vlm (69642)

          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

    • by David Chappell (671429) on Thursday July 08, 2010 @09:12AM (#32838572) Homepage

      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.

      • by phoebe (196531) on Thursday July 08, 2010 @09:32AM (#32838822)
        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.
        • by Anonymous Coward on Thursday July 08, 2010 @10:23AM (#32839648)

          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)

          by Anonymous Coward

          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.

    • by adosch (1397357)

      I think you're missing the point, brilliance and usefulness of this. To put a rest to your argument, being behind a private network is just banter; you can still use a local time clock source from an internal server, server it up with NTP and let all your internal hosts connect to it to sync time. However, the point is that it's not a reliable time source, and even a network time nazi or your basic shell account user will tell you that the times are going to vary enough between your nodes to be bothersome

      • Re: (Score:3, Interesting)

        by EriktheGreen (660160)
        Any IT organization still buying its own atomic clocks is probably a government operation. Seriously, GPS based local NTP servers have been out for years.

        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

        • by amorsen (7485)

          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)

            by EriktheGreen (660160)

            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

      • by vlm (69642)

        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.

    • by TheCarp (96830)

      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

    • by mbone (558574)

      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.

    • by Odin's Raven (145278) on Thursday July 08, 2010 @11:31AM (#32840584)

      NTP solved this ages ago by distributing atomic clock accuracy through the network.

      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.

  • by mrt_2394871 (1174545) on Thursday July 08, 2010 @08:49AM (#32838250)

    I can imagine the speaking clock:

    "At the third stroke, it will be, most likely, sixish"

  • Use GPS (Score:2, Insightful)

    by maroberts (15852)

    They have atomic clocks on board and GPS receivers therefore give highly accurate time.

    • Re:Use GPS (Score:4, Interesting)

      by bickerdyke (670000) on Thursday July 08, 2010 @09:09AM (#32838542)

      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)

        by Hognoxious (631665) on Thursday July 08, 2010 @09:14AM (#32838600) Homepage Journal

        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)

          by bickerdyke (670000)

          - 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)

            by mikechant (729173)

            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)

            by mea37 (1201159)

            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)

          by gnieboer (1272482)

          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

          • by Rich0 (548339)

            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:3, Interesting)

        by arth1 (260657)

        A GPS receiver will be useless as the GPS time currently is (IIRC) 12 seconds ahaed of UTC.

        GPS doesn't honor leap seconds.

        YRW, it's behind, not ahead.

        And that's why you have /usr/share/zoneinfo/right hierarchy anyhow:

        $ TZ=:America/New_York date; TZ=:right/America/New_York date
        Thu Jul 8 09:14:01 EDT 2010
        Thu Jul 8 09:13:37 EDT 2010

      • Because leap seconds are not added predictably(the International Earth Rotation and Reference Systems Service does try to announce them with some notice; but the earth is pretty wobbly), that would be an issue for any system that has to spit out UTC for years or decades without any updates aside from GPS; but for pretty much any other system(and basically any internet or large internal network connected PC would qualify), who cares?

        The GPS gives you a highly stable timebase for peanuts, and then you can
      • GPS is fine because the reason to have time synced at different sites is to correlate events at those sites. As long as they're in sync, it doesn't generally matter if they are exactly correct with respect to the wall clock. If you need to compare event time to wall clock time, you do the math for the time period in question.

        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

      • by Retric (704075)

        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.

        • 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)

        by AmigaAvenger (210519) on Thursday July 08, 2010 @09:44AM (#32839012) Journal
        Might want to doublecheck your facts. GPS knows about the time difference, which isn't 12 seconds either btw, it is 19. The complete time message, which includes the correct amount, is broadcast every 12.5 minutes, so its possible that when you cold boot a gps, it will be off some amount of time before that is received. (12 seconds is common for lots of GPS engines, they have built in correct for the first 7 seconds of correction, but need the updated time message after connection to get the rest of the update)
      • The GPS satellites are corrected to take relativistic distortion into account, leap seconds are trivial compared to that.
      • by Shatrat (855151)
        GPS is the most widely used synchronization source for synchronous optical networking.
        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.

  • by Pojut (1027544) on Thursday July 08, 2010 @08:51AM (#32838268) Homepage

    ...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?

    • by Schezar (249629) on Thursday July 08, 2010 @09:00AM (#32838420) Homepage Journal

      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.

      • by Pojut (1027544)

        Cool! Thanks for the mini-lesson :-)

      • by Rich0 (548339)

        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.

    • Thinking the IRS and your local state and community tax collectors would like to know everybody whose e-return is >= 1 microsecond late. That penalty money is important to g'ment - particularly in these days when an industrial base decimated by inequitable free trade provides ever less tax revenue.
    • ...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?

      ... and yet would not be willing to use ntp or buy their own time base.
  • So, someone's invented ntp_time? That's only been around collecting time from time servers, many of which are atomic clock connected, since about 1985.

    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

    • by the_olo (160789) on Thursday July 08, 2010 @09:09AM (#32838532) Homepage

      So, someone's invented ntp_time? That's only been around collecting time from time servers, many of which are atomic clock connected, since about 1985.

      ...

      Seriously, could the editor that greenlighted this have done a google search or something?

      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)

        by CODiNE (27417)

        The RADclock project (formerly known under 'TSCclock') aims to provide a new system for network timing within two years.

        Damn 2 years?? I suspect the time is somewhere between 2009 and 2011...

    • Re: (Score:3, Interesting)

      by thijsh (910751)
      You missed the point... NTP is a mechanism to get time from an authority, and so is GPS (which probably uses a souped-up NTP-ish system to sync with ground control). This system is about being independent from authoritative servers. And there can be legitimate purposes why you might need it so it's a good thing they research it... Some of the reasons to want this might be:
      - Reduce the potential points of failure from one single bottleneck to infinite peers.
      - Require no configuration (some old routers for
      • Nah. Apart from the last two, all these items are addressed by the GPS receivers. Companies with dire needs for accurate time can use two, they never go down when the network is down, they can work in a mobile environment, multiple corporate sites can be assured of having synced time regardless of network delays.... I'm all for the development of new algorithms and code, but this is about as interesting as an update to the Windows clock program.
        • by thijsh (910751)
          What makes you think the US won't sabotage GPS when they need to? Especially since weapons and troops now use GPS frequently to find targets they can easily send faulty data to mess with the enemies equipment... This is not really all that far fetched in a war scenario! Also an internet kill switch could easily encompass GPS... If you need accuracy no matter what (even in the case of a war, and in isolation of the rest of the world) GPS does not help.

          But even the outside scenario of a time synchronizing s
          • So let me get this straight... you're stating that the reason this should be a Slashdot story is because A) The US government may sabotage GPS, and in such a situation our first concern would be accurate time on our computers and B) When we go to mars and/or have problems with time dilation due to near lightspeed travel, we'll need the ability to sync local time over a variable latency network because atomic clocks will still be too expensive?

            I'm gonna go out on a limb and say this is not a big deal.

            • by thijsh (910751)
              I'm saying if they found an interesting way to both improve NTP with time difference *and* make it work stand-alone independent from central servers that's called a technological improvement. You might not see the merit right now, but that's not the point... It's legitimate news for nerds! Come on, admit it, half the shit we love has absolutely no link to the real world whatsoever... :)
              • It's not that it's not linked to the real world, it's that it's not news for anyone.

                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

                • by amorsen (7485)

                  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.

                  • Sounds anecdotal. But you echo what I've said above.. if you really care about time you won't use NTP or any other time sync protocol based on a variable latency network.
                • Re: (Score:3, Interesting)

                  by RobertLTux (260313)

                  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.

        • by amorsen (7485)

          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.

          • 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.

  • 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)

      by whyde (123448) on Thursday July 08, 2010 @09:09AM (#32838534)

      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."

      • Tee hee.
        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)

          by swb (14022)

          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

  • by B5_geek (638928) on Thursday July 08, 2010 @09:02AM (#32838456)

    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."

  • Can't wait to see all computers set their clocks to January 1st, 1980.

  • "A man with a watch knows what time it is. A man with two watches is never sure." -- Segal's Law.
    • A man with a watch with neither of them moving knows what time it is. If either is moving relative to the other, you cannot be sure.
  • Something that can measure my sexual stamina properly ;-)
  • This reminds me of the old Swiss watchmaker. Every day at noon, regular as clockwork, on office worker walked past the watchmaker's window on his way to lunch. This was the watchmaker's reminder to carry out his daily clock setting, so every time the office worker went past, the watchmaker checked that all of his clocks indicated noon.

    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
  • 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.

  • 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

    • by amorsen (7485)

      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.

      • 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

  • 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

  • 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

  • by Goldsmith (561202) on Thursday July 08, 2010 @09:33PM (#32846838)

    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?

One good reason why computers can do more work than people is that they never have to stop and answer the phone.

Working...