Re: Seeking clarifaction of tai64nlocal and leap seconds
"Andy Bradford" <[email protected]> 20 Sep 2012 18:12:57 -0600
| Newsgroups | gmane.comp.djb.syslog |
|---|---|
| Message-ID | <[email protected]> |
Thus said Michael Sierchio on Thu, 20 Sep 2012 10:59:31 PDT: > These are NOT serious timekeeping mechanisms - not sufficient to keep > a group of computers within 1ms of each other locally, or within 10ms > of actual TAI (not what your computer's clock says). The claim made on the webpage is: clockspeed uses a hardware tick counter to compensate for a persistently fast or slow system clock. Given a few time measurements from a reliable source, it computes and then eliminates the clock skew. He then mentioned his own observations of how well it worked: Typical success story: I started clockspeed on one of my Pentium computers at home on 1998-05-05. I ran sntpclock (through a 28.8 dialup line) once on 1998-05-05 and once on 1998-05-30. On 1998-08-22, after no network time input for nearly three months, the clock was just 0.21 seconds off. Nowhere does he claim that it will eliminate the need for a GPS source or other time sources. He only claims that his software will eliminate clock skew. But, after 3 months of no network time input, 0.21 seconds off seems pretty impressive to me. > Your clock's frequency changes with the temperature such that it makes > a fairly accurate thermometer, and there is also noise (jitter). > Unless you have a reliable PPS mechanism and a kernel that can > discipline its clock with it, don't take it too seriously. ;-) Well, I guess it will take some time to be proven. I only started clockspeed on my soekris this morning, so maybe in a few months time (after having trained it as per the instructions) I can comment further. How can I measure whether or not my clock is within 1ms of a time server? Will this be sufficient: $ sntpclock 130.126.24.44 | clockview before: 2012-09-20 18:08:55.646085000000000000 after: 2012-09-20 18:08:55.650070167348325252 As you can see, after my first measurement, the clock is still drifting, but not too bad yet. It's possible, as you say, that this isn't a serious method for doing clock synchronization. I'll have a look at the website you mentioned and see if it elaborates further on the topic. Andy