[ntp:questions] problem with synchronizing two comps to each other
brad at stop.mail-abuse.org
Thu May 19 13:08:37 UTC 2005
At 2:37 PM +0200 2005-05-19, Mike wrote:
> For some reasons I need to synchronize two computers to each other.
> Synchronization with GMT time is not necessery. I just want them to
> share the same time. What accurancy can I get using NTP?
Depends on your hardware. You don't care about synchronizing
with outside sources, but do you care about whether or not you gain
or lose time relative to those outside sources, if you should leave
the system running disconnected for a long period?
> 1 ms would
> be perfect. How can I do it? I suppose I need some Linux for it, are
> there any special distribution giving good precision?
You could do it with Linux, but you'll probably want the PPSKit
patches if you want to maintain any level of relative accuracy
between the two machines over time, and this is still going to depend
on the hardware. Unpatched Linux and Windows have the problem that
they tend to drop interrupts when they're very busy, and this
destroys any ability to keep any kind of accuracy.
Solaris and the members of the BSD family tend to lose fewer
interrupts than even a PPSKit-patched version of Linux, but you might
have other reasons why you'd prefer to run Linux instead -- you'll
have to make that decision yourself.
> I thought about connecting both comps with an ethernet cable, and asking
> one of them to synchronize with the other one. I thought I've done it, but
> it took like 3 seconds and when checking with
> ntpq -q IP_adress
> it started changing, 1ms each second, is it possible? (it's more than
> 10 minuts every 24hours)
If you want to run in disconnected mode, you need to let ntpd do
it's thing the right way. This means setting up one machine as the
"master", which syncs only to the system local clock, and then
provides that time to it's client(s). The client(s) would list only
that one master as their time source.
On the master, you're going to want /etc/ntpd.conf files that
looks something like this:
server 127.127.1.0 # Local clock
fudge 127.127.1.0 stratum 10 # Undisciplined
On the client(s), assuming the master had the IP address
10.0.1.1, their one-line /etc/ntp.conf might look something like this:
server 10.0.1.1 iburst
All this does is set up the one machine to look to the hardware
system clock and consider that to be a valid external reference,
which it then provides to any clients who connect to it. Note that
it is artificially set to stratum 10, so that any client who has a
path to another time server with a real external reference clock is
unlikely to sync to your internal master (bogomaster?), but any other
clients should sync to your internal master just fine.
Now, if the hardware system clock of the master drifts over time,
there's nothing you can do to detect that, or to correct for it. And
if you don't set the time on that machine manually to a value that is
reasonably close to correct, then your clients are also going to have
their clocks be off.
Finally, if the clock on the master has significant drift, this
is likely to cause problems for your clients as they try to adjust
their clocks to keep up with your master. If your master runs too
fast, then clients which would naturally run slow will have a very
difficult time keeping their clocks adjusted so that they can stay in
sync. Likewise, if the master runs too slow, then fast clients are
going to have a hard time slowing down. Even if you have a good
external reference and the master is very closely sync'ed to it, you
will find that a surprising number of clients have hardware system
clocks that either run too fast or too slow that they can't keep
their clocks very closely aligned with that true master, so it's
going to be considerably harder to keep them in sync with a
Now, with a good external refclock and a good machine connected
to it with a suitable OS that is not going to lose interrupts, you
could reasonably hope that your master would have its clock within
one microsecond or so of "true" time. You could also hope that
clients on the local Ethernet network might have their clocks within
a microsecond or two of the master, if they're on good hardware with
a good OS, and neither the network nor any of the machines are too
Beyond that, you're likely to have difficulty maintaining clock
sync down to the microsecond level. On my old Apple Macintosh
PowerBook G3 laptop running MacOS X 10.3.x, connected to a wireless
network and using multiple upstream stratum 2 and stratum 3
timeservers (most of which are no more than 50ms away), I usually
manage to keep this machine within five microseconds or so of "true
time", once the machine is up and running and stable for a while.
But running in disconnected mode is going to make your life much
more difficult, since you won't have any external reference to
compare to and you won't have any way of knowing how fast or slow the
individual hardware system clocks of the machines would natively run,
how badly those machines might cope with losing interrupts, etc....
You'll have a lot of unknowns there that you're trying to
compensate for, and no way to accuractely measure them.
Brad Knowles, <brad at stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
More information about the questions