[ntp:questions] problem with synchronizing two comps to each other

Brad Knowles 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 
disconnected master.


	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 
heavily loaded.

	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 mailing list