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