[ntp:questions] Re: Advice on sync clock between cluster of linux v2.6 to +-1us
Richard B. Gilbert
rgilbert88 at comcast.net
Thu Jan 13 01:21:05 UTC 2005
> Thank you Brad, Richard and Helmut for your prompt replies.
> Originally I was thinking a connection setup similar to would suffice:
> External clock Reference --> Master Node --> Other computers nodes via
> I did not realise that inherent delays as Richard mention in Ethernet
> would be the best achievable accuracy. Maybe a setup below would be
> more appropriate:
> External Reference --> All computer nodes using a signal booster/splitter
> Even still, I doubt this would guarantee the accuracy between the
> nodes of +- 1 microsecond.
> Helmut - When I mentioned 'cluster', I meant a group (< 10) of
> computers connected by Ethernet.
> I have been given this more thought today and suspect I am approaching
> this incorrectly.
> The problem resolves event timing in a test rig. Each computer node
> are part of the test rig and basically act as an I/O interface to the
> system-under-test. Each node would be given a list of event
> instructions and the time stamp when the event should be triggered.
> This time stamp would be relative to the start of the test and hence
> my original statement that "actual time is not required".
> Thinking aloud - Another solution could be using the processor local
> clock. I believe all 386 processors have them and assume their drift
> would not be excessive. (Anyone have statistics on this?) Each node
> loads their instructions and wait for the master node to send a start
> signal. The master node could send a Ethernet broadcast 'start' packet
> (assuming the network infrastructure sends broadcast data to all ports
> at the same time). On receipt, each client node records their local
> clock time stamp as the "start time" and immediately run the test. All
> the events in the test would be triggered relative to this "start
> time". I wouldn't like to say how accurate this is but willing to take
> opinions or better solutions.
> All the best,
I think the whole idea may have serious problems! To start with, the
computers I am familiar with don't update their clocks very often, ten
milliseconds or 100 ticks per second is typical. Some can do 1000 ticks
per second. If the clocks are updated only every ten milliseconds,
it's not going to be practical to get machine B to trigger event B
exactly 75 microseconds after machine A triggers event A.
Think, for example, of the time display on your cellular phone. Mine
displays hours and minutes. It advances to the next minute within a few
microseconds of the UTC minute since it's slaved to the CDMA reference
signal which in turn is synchronized with GPS. I can know exactly
(well, within microseconds) what time it is once per minute! If I want
to do something exactly seven seconds after the top of the minute, my
cell phone can't help me!
Your best bet might be a one MHz oscillator driving a counter. Decode
the counter output to trigger each event. You can use the counter
output to timestamp measurements. Another possibility is an IRIG time
signal such as those used by missile test ranges.
Interrupt latency is another issue that is likely to be troublesome.
Most general purpose computers and operating systems do not guarantee to
handle interrupts fast enough to handle microsecond timing. You need an
operating system designed for real-time and maybe even hardware designed
for real-time systems.
The the sort of thing you are trying to do can be and has been done but
I doubt if it has been done by synchronizing the clocks of general
purpose computers and operating systems.
More information about the questions