sync computer clock ticks
I forgot two things!
(1) It's all Linux, with stock kernel.org kernels, see below.
(2) see comment about the application below.
Christian Vogel schrieb:
at work, I use it to sync all servers and workstations to 4 stratum 1
NTP-servers. I get ~100us offset usually. Without special hardware I'd
say that 1usec is not possible.
Server, Gig-Ethernet, 4 hops (>=Gigabit) to ntp:
*ntp2-rz.rrze.un .GPS. 1 u 758 1024 377 1.225 -0.179 0.068
(HP DL380-G3, Dual 3.2 GHz P4, no powersaving)
-> Temperature fluctuates +/- 3 Deg-Celsius every 20sec due to HVAC
Kernel 2.6.21.3 SMP
Client, 100Mbit, 5 hops (last 4 are better than Gigabit):
*ntp2-rz.rrze.un .GPS. 1 u 987 1024 377 1.577 -0.111 0.091
(P4-Celeron, 2.4 GHz, currently throttled to 300 MHz)
-> Temperature currently stable and possibly very cool, have not
been in my office for a week :-)
Kernel 2.6.22.1 PREEMP
And: We should not forget the original poster's question about if 1 usec
precision can be achieved? I'd say that the most important thing about
this question is, what application the precision is needed for.
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.
Scatterbrained,
Chris
In message: 477E816D.5010803@vogel.cx
Christian Vogel vogelchr@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
M. Warner Losh wrote:
In message: 477E816D.5010803@vogel.cx
Christian Vogel vogelchr@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.
Someone has even implemented it in software (with degraded performance).
See:
http://ieee1588.nist.gov/
Bruce
In message: 477E8D67.1010505@xtra.co.nz
Bruce Griffiths bruce.griffiths@xtra.co.nz writes:
: M. Warner Losh wrote:
: > In message: 477E816D.5010803@vogel.cx
: > Christian Vogel vogelchr@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
differences.
: Someone has even implemented it in software (with degraded performance).
: See:
: http://ieee1588.nist.gov/
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.
Warner
On Fri, Jan 04, 2008 at 10:28:33AM -0700, M. Warner Losh wrote:
I have no experience with gige networks, but the best I've been able
to do on 100baseT networks is 50us. I'm unsure what <1us
synchronization really means, since that's starting to get below the
level of system calls on fast machines.
My experience in the late 90s with syncing Linux was based on
using serial port 1 PPS interrupts with custom code in the kernel to
optimize the serial port modem interrupt path. Time stamps of this
interrupt versus the hardware based microclock (based on an incrementing
counter in the CPU) were used to drive the NTP PLL which computed the
frequency error and time offset for the kernel PLL.
I found the microclock readings of time of day on the 1 PPS were
usually within 1 us (there were a few late ones due to interrupt off
intervals of course). This was on fairly slow server class hardware
(Pentium Pro at 200 MHz).
On ethernet I would not expect that level of accuracy due to the
inherent CSMA/CD algorithm jitter... plus of course whatever the bridge
in the star hub introduces...
Obviously once one gets into the microsecond area one gets into
the world of software relativity where what one means by time of day
depends on where one is looking. What I was using to judge performance
was what an interrupt level call to microclock returned... but inside a
larger software system this will obviously be skewed by the various
calling delays to get to the kernel...
--
Dave Emery N1PRE/AE, die@dieconsulting.com DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."
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.
The company i work for makes high performance interconnect solutions
for super computers. i'm working on a demo where we're sending data
around a ring and i wanted to timestamp all the packets as it hits
each node of the ring. the servers could be under some stress when
this is running.
i had a feeling what i wanted to do isn't possible, but i figured i'd
ask some experts before i give up.
Michael Di Domenico wrote:
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.
The company i work for makes high performance interconnect solutions
for super computers. i'm working on a demo where we're sending data
around a ring and i wanted to timestamp all the packets as it hits
each node of the ring. the servers could be under some stress when
this is running.
i had a feeling what i wanted to do isn't possible, but i figured i'd
ask some experts before i give up.
Unless you use packet time stamping cards as used in network
characterisation.
Errors of around 120ns or so are typical, see:
http://nistboulder.net/Presentations/FCSEFTF2003(final).pdf
http://nistboulder.net/Presentations/FCSEFTF2003%28final%29.pdf
Suitable PCI cards are available.
Bruce