[time-nuts] sync computer clock ticks
M. Warner Losh
imp at bsdimp.com
Fri Jan 4 15:03:27 EST 2008
In message: <477E8D67.1010505 at xtra.co.nz>
Bruce Griffiths <bruce.griffiths at xtra.co.nz> writes:
: M. Warner Losh wrote:
: > In message: <477E816D.5010803 at vogel.cx>
: > Christian Vogel <vogelchr at vogel.cx> writes:
: > : For example, do you want to timestamp interrupts to synchronize
: > : machinery? Or just note down the timestamps of bittorrent downloads very
: > : precisely? Just synchronizing an otherwise idling computer is probably
: > : much easier than a machine that is doing a lot of additional work that
: > : can mess up the timekeeping by clogging the processor or just creating
: > : varying stress on the power-supply lines.
: > That's the real question. Like I said before, when you are down to
: > the microsecond level, what good is that? The jitter from system
: > calls and such is going to be high enough to make that not completely
: > useful. And if you are trying to do things to hardware with software
: > that requires that level of synchronization, you aren't going to get
: > it without timestamping done in hardware of some mutually observable
: > event (pps, packets on the network, etc).
: > Warner
: PTP achieves submicrosecond synchronisation over small LANs without
: network switches.
: It uses hardware time stamping of LAN packets.
Right. This is hardware time stamping of mutually observable events
(the two way time exchange).
One can measure down to nanosecond levels with custom hardware with
1588. Sam Stein presented a paper at 2006 PITI that talked about an
average of 2.5ns with a standard deviation of 0.9ns in measuring clock
: Someone has even implemented it in software (with degraded performance).
Right, and the performance here is not much better than ntp, at least
in the tests that I've done. The jitter is slightly better.
More information about the time-nuts