[time-nuts] TimeKeeper?

mike cook michael.cook at wanadoo.fr
Mon Feb 22 21:33:55 UTC 2010

Le 22/02/2010 03:02, Alexander Sack a écrit :
> Has anyone seen this:
> http://www.drdobbs.com/linux-open-source/223000197;jsessionid=LEYQTVQD4D24TQE1GHPCKH4ATMY32JVN?pgno=1
> Excuse if its been talked about but I don't see it in my mail
> archives.  I thought some of the ntpd'ers on this list might be
> interested.
> -aps
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
Am I cynical in thinking that the article is just product sales pitch?
The writer has not been objective in using realistic NTP configurations 
and practices by taking the worst case , where neither the local 
oscillator drift is known (deleting the drift file)nor the local clock 
value at NTP startup is near reality (deliberate offset ). No one is 
going to either remove their drift file without good reason, nor allow 
arbitrairy local clock values at startup.
That said NTP is very conservative in validating the stability of clock 
sources. I have not delved into the code, but it is obvious that even a 
refclock like a GPS receiver doesn't get any favours. Why should it? Who 
knows whether the clock is dodgy or not?
However the times he was reporting for the offsets to drop to less than 
1ms did look excessive.

Anyway, just to see if I was seeing  a similar profile, I did a 
stop/start on a Soekris server/client pair . I don't have the same 
software/hardware config but that shouldn't make a huge difference.
  ntp is 4.2.0 on FreeBSD 6.2
  no fancy hardware.
Motorola Oncore UT+ on COM2
  reset server conf to sample JUST its UT+ PPS receiver. using the 
oncore driver out of the box.

   stopped daemons
   backed up then removed the /etc/ntp/drift file
   removed all the loopstat/peerstat logs
   shifted the system clock down 500ms on both client and server
   restarted the server daemon
   wait 30s
   restart the client daemon

Then checked how long client / server got back to a <1ms offset

  From this test it took the server approx 600secs to get to an offset 
less than 1ms.
  The client, started 30secs after the server was sync'd  to the same 
offset  shortly afterwards.
  Not brilliant, but not as bad as those stats shown in the article for 

  I then did a restart with the original drift files and a clock 
estimate from ntpdate directed at NIST.
  This is a more realistic event. since even in the event of a system 
crash, that data is available.
  Even then, it is a bit unusual for both client and server to be 
restarted at the same time.

In this case, the ntp server was serving with an offset of less than 1ms 
after 2 mins and the client sync'd just about as fast.

So in more realistic ;), one refclock scenario NTP can still get down to 
a reasonable accuracy in good time after a restart and in a similar 
timeframe to Timekeeper.

More information about the time-nuts mailing list