Hi,

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? 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?
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)

thanks in advance for all the help

Mike

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@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.

so you're telling, that it will be easier to update time from external 
server? beacause I thought, that if 1 comp (master) keeps the time, the 
other one (client) will adjust to it over LAN network. That it will give 
beter results in setting the same time on both comps.

I want to do that, because I want to measure the delay (latency) of 
packet (the time between send and recieved). It's done by a software, 
calleg mgen, which sends packets with timestamps, and then reciever 
reads this timestamp, reads his own time, and puts them both into the 
text file. The test should probably take about 24h max, so thats the 
time i need these both computers to be synchronized with accurancy of 1 
ms, or maybe more, if there is no way in keeping 1ms accurancy.

Or maybe you have other hint's how to measure the delay?

Mike

"Mike" <miodek.STOP.SPAM@thebestnudes.com> wrote in message
news:d6i7kg$3tr$1@korweta.task.gda.pl...

> so you're telling, that it will be easier to update time from external
> server? beacause I thought, that if 1 comp (master) keeps the time,
> the other one (client) will adjust to it over LAN network. That it
> will give beter results in setting the same time on both comps.

No, it will avoid one specific failure mode. The one where one server is
running fast, and one is running slow, both with respect to real time,
and neither speed difference is out of spec (500 PPM) for NTP, but the
difference between them is. For instance, if one host is 350 PPM fast
and the other is 350 PPM slow, they could both synchronise to UTC, but
not to the other when it is free-running, because that is a 700 PPM
difference and NTP simply quits at 500.

Also, a free-running clock may not run at the same speed all the time.
Reference clocks do, by design. Since speed and time difference are
not caught up with immediately, that will result in higher offsets.

Groetjes,
Maarten Wiltink

Mike wrote:

> so you're telling, that it will be easier to update time from external 
> server? beacause I thought, that if 1 comp (master) keeps the time, 
> the other one (client) will adjust to it over LAN network. That it 
> will give beter results in setting the same time on both comps.
>
> I want to do that, because I want to measure the delay (latency) of 
> packet (the time between send and recieved). It's done by a software, 
> calleg mgen, which sends packets with timestamps, and then reciever 
> reads this timestamp, reads his own time, and puts them both into the 
> text file. The test should probably take about 24h max, so thats the 
> time i need these both computers to be synchronized with accurancy of 
> 1 ms, or maybe more, if there is no way in keeping 1ms accurancy.
>
> Or maybe you have other hint's how to measure the delay?
>
> Mike

Just how big a network latency are you trying to measure?  How 
accurately do you need to measure it?   On a LAN, delays are typically 
less than 500 microseconds.   To measure the transmission delay from 
machine A to machine B both clocks will need to be within considerably 
less than 500 microseconds.   Next, you are trying to synchronize the 
two machines using the same network you are trying to measure???  The 
uncertainty in transmitting time via NTP from one machine to another is 
one half of the round trip delay!

I think that you need to think a lot more carefully about what you are 
trying to do or at least describe it more carefully.

At 5:04 PM +0200 2005-05-19, Maarten Wiltink quoted "Mike" 
<miodek.STOP.SPAM@thebestnudes.com>:

>>  so you're telling, that it will be easier to update time from external
>>  server? beacause I thought, that if 1 comp (master) keeps the time,
>>  the other one (client) will adjust to it over LAN network. That it
>>  will give beter results in setting the same time on both comps.
>
>  No, it will avoid one specific failure mode. The one where one server
>  is running fast, and one is running slow, both with respect to real
>  time, and neither speed difference is out of spec (500 PPM) for NTP,
>  but the difference between them is.

	It will avoid that failure mode, as well as failure modes 
involving the entire network running fast or slow (as clocked from 
the bogomaster), so that aggregate measurements over time may be 
skewed.


	Mike -- Please note that my original message mentioned 
microseconds, and I know that you were talking about milliseconds. 
However, there are issues that computers face in synchronizing their 
clocks to an upstream server which will affect you in pretty much the 
same way, regardless of whether you're looking for millisecond or 
microsecond resolution.

	Millisecond resolution is easy enough to achieve with NTP, and 
indeed I would say that it's hard for NTP to be that far out -- if 
you're off by that much, that's usually pretty easy to detect and 
you'll get your clock marked as a falseticker.


	If you set up NTP correctly within your local network, and you 
have good hardware with a good OS that is properly configured, I 
would think that you should be able to easily achieve accuracy levels 
in the single-digit microsecond range.  Even the double-digit 
microsecond range would be more than enough for your needs.

	Assuming you get NTP to work at all, I would think that it should 
actually be difficult to have accuracy that is only as good as the 
triple-digit microsecond range.

-- 
Brad Knowles, <brad@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.

Brad Knowles <brad@stop.mail-abuse.org> writes:

> At 2:37 PM +0200 2005-05-19, Mike wrote:
> 
> >                                                            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.
> 

PPSKit-patch implements the kernel PPSAPI which is useful when you
have a good GPS with PPS-signal attached to the computer. In which way
does this relate to loosing timer interrupts? or the OPs question?

A normal Linux machine with no local reference clock (GPS) attached
_should_ _not_ be PPSKit-patched!

Loosing interrupts comes from having HZ set to high during high
load. 


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

Lots of people run NTP on Linux with no problems. Lots of companys
sell Linux based NTP-servers.

---
        
        Bj�rn

On 2005-05-19, Bjorn Gabrielsson <bg@lysator.liu.se> wrote:

> Lots of people run NTP on Linux with no problems. Lots of companys
> sell Linux based NTP-servers.

The choice of hardware and kernel version is significant. I've had
great success running NTP on Linux/x86 systems (Intel Pentium, and AMD
K6-III). And I've found Linux on an AMD Geode system (soekris 4801) to
be unsuitable for NTP.

YMMV

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/

At 4:25 PM +0000 2005-05-19, Bjorn Gabrielsson wrote:

>  PPSKit-patch implements the kernel PPSAPI which is useful when you
>  have a good GPS with PPS-signal attached to the computer. In which way
>  does this relate to loosing timer interrupts? or the OPs question?

	Sorry, I was under the impression that the PPSKit patches also 
helped with the overall problem of losing interrupts.  My bad.

>  Lots of people run NTP on Linux with no problems.

	And lots of people have problems with NTP on Linux.

>                                                     Lots of companys
>  sell Linux based NTP-servers.

	How many of those are not patched with the PPSKit?  And of those 
that are not patched, how many work well?  And how many people have 
resolved the networking issues with Linux?


	I'm not saying that Linux won't work.  However, it has a number 
of well-known areas where it tends to have difficulties relative to 
NTP.  In addition, there are a much greater number of people using 
Linux who are neophytes, and an there is increased ratio of neophytes 
to experts.  There are also some issues with the networking code in 
current versions of Linux.

	The result is a serious issue that needs to be addressed any time 
someone talks about doing NTP using Linux.

	If they're already an expert and they know what the PPSKit 
patches do and whether or not they need them, then we're down to 
things like the networking code, or problems inherent to anyone 
trying to use desktop-grade computers as servers, or perhaps issues 
internal to NTP itself.

-- 
Brad Knowles, <brad@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.

Steve Kostecke <kostecke@ntp.isc.org> writes:

> On 2005-05-19, Bjorn Gabrielsson <bg@lysator.liu.se> wrote:
> 
> > Lots of people run NTP on Linux with no problems. Lots of companys
> > sell Linux based NTP-servers.

> The choice of hardware and kernel version is significant. I've had
> great success running NTP on Linux/x86 systems (Intel Pentium, and AMD
> K6-III). 

Me too (PentiumII, ULV Celeron, AMD64)

> And I've found Linux on an AMD Geode system (soekris 4801) to
> be unsuitable for NTP.

I think, I have read a well known freebsd guru prefer AMD Elan 520 (soekris
4501) over the 4801. Even though the Elan 520 (100MHz 486/class) a
older slower processor than the Geode (266MHz pentium class).  

Isn't there some kind of "27MHz timer" in the Geode that is related to
the NTP issue? Think there is a linux kernel patch for this beeing
merged into Linus tree quite recently.

> YMMV

As always... :-)

--
        Bj�rn

Brad,

Brad Knowles wrote:
> At 4:25 PM +0000 2005-05-19, Bjorn Gabrielsson wrote:
> 
>>  PPSKit-patch implements the kernel PPSAPI which is useful when you
>>  have a good GPS with PPS-signal attached to the computer. In which way
>>  does this relate to loosing timer interrupts? or the OPs question?
> 
> Sorry, I was under the impression that the PPSKit patches also
> helped with the overall problem of losing interrupts.  My bad.

Yes, Bjorn is right. As the name says, PPSKit is only required if you want
PPS support for your kernel, i.e. if you have a refclock which generates
PPS pulses.
 
>>  Lots of people run NTP on Linux with no problems.
> 
> And lots of people have problems with NTP on Linux.
> 
>>                                                     Lots of companys
>>  sell Linux based NTP-servers.
> 
> How many of those are not patched with the PPSKit?  And of those
> that are not patched, how many work well?  And how many people have
> resolved the networking issues with Linux?
> 
> I'm not saying that Linux won't work.  However, it has a number
> of well-known areas where it tends to have difficulties relative to
> NTP.  

I think machines without a refclock don't require the PPSkit patch. If
machines are configured as standard clients which poll the time from an NTP
server, I'm not aware of any problems with Linux.

> In addition, there are a much greater number of people using 
> Linux who are neophytes, and an there is increased ratio of neophytes
> to experts.  There are also some issues with the networking code in
> current versions of Linux.
> 
> The result is a serious issue that needs to be addressed any time
> someone talks about doing NTP using Linux.

AFAIK there are some problems with broadcast/multicast modes because things
have been implemented in Linux in a different way as commonly known for
other Unices. The legacy way works perfectly.
 
> If they're already an expert and they know what the PPSKit
> patches do and whether or not they need them, then we're down to
> things like the networking code, or problems inherent to anyone
> trying to use desktop-grade computers as servers, or perhaps issues
> internal to NTP itself.

I've also seen that the ACPI implementation in a PC BIOS affects the quality
of time keeping. With ACPI enabled there's been some jitter in the system
clock, but after ACPI had been disabled by the BIOS programmers, the jitter
disappeared. You can't blame things like this on Linux.
 
Best regards,

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Hello,
sorry if I step in this discussion. I'm running a couple of 
stratum 1 servers, one based on linux and the other based on 
sparc/solaris 9. Both are synchronized to the same gps receiver (via
a custom interface I designed, which basicly takes one rs-422 input
and gives 2 rs-232 outputs). Here are both ntptime outputs:

Linux: 
ntp_gettime() returns code 0 (OK)
  time c63864a2.aaecd038  Fri, May 20 2005 15:29:06.667, (.667676834),
  maximum error 758 us, estimated error 1 us, TAI offset 1073821304
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 14.526 us, frequency -229.131 ppm, interval 256 s,
  maximum error 758 us, estimated error 1 us,
  status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
  time constant 4, precision 3.582 us, tolerance 496 ppm,
  pps frequency -229.131 ppm, stability 0.013 ppm, jitter 3.225 us,
  intervals 1394, jitter exceeded 2501, stability exceeded 32, errors 0.

Solaris:

ntp_gettime() returns code 0 (OK)
  time c63864d7.676f1000  Fri, May 20 2005 15:29:59.404, (.404038),
  maximum error 1193 us, estimated error 3 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 1.000 us, frequency -6.402 ppm, interval 256 s,
  maximum error 1193 us, estimated error 3 us,
  status 0x107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL),
  time constant 0, precision 1.000 us, tolerance 512 ppm,
  pps frequency 0.000 ppm, stability 0.000 ppm, jitter 1.000 us,
  intervals 116977, jitter exceeded 509, stability exceeded 8, errors 532.

I'm not very expert on how to assess these numbers, so can anyone give
advices if things are working well and maybe if I can improuve
something? Ntp version is 4.2.0 and the linux host runs 2.4.30+NANO
kernel.

Regards

Francesco

Francesco Messineo wrote:

>Hello,
>sorry if I step in this discussion. I'm running a couple of 
>stratum 1 servers, one based on linux and the other based on 
>sparc/solaris 9. Both are synchronized to the same gps receiver (via
>a custom interface I designed, which basicly takes one rs-422 input
>and gives 2 rs-232 outputs). Here are both ntptime outputs:
>
>Linux: 
>ntp_gettime() returns code 0 (OK)
>  time c63864a2.aaecd038  Fri, May 20 2005 15:29:06.667, (.667676834),
>  maximum error 758 us, estimated error 1 us, TAI offset 1073821304
>ntp_adjtime() returns code 0 (OK)
>  modes 0x0 (),
>  offset 14.526 us, frequency -229.131 ppm, interval 256 s,
>  maximum error 758 us, estimated error 1 us,
>  status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
>  time constant 4, precision 3.582 us, tolerance 496 ppm,
>  pps frequency -229.131 ppm, stability 0.013 ppm, jitter 3.225 us,
>  intervals 1394, jitter exceeded 2501, stability exceeded 32, errors 0.
>
>Solaris:
>
>ntp_gettime() returns code 0 (OK)
>  time c63864d7.676f1000  Fri, May 20 2005 15:29:59.404, (.404038),
>  maximum error 1193 us, estimated error 3 us
>ntp_adjtime() returns code 0 (OK)
>  modes 0x0 (),
>  offset 1.000 us, frequency -6.402 ppm, interval 256 s,
>  maximum error 1193 us, estimated error 3 us,
>  status 0x107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL),
>  time constant 0, precision 1.000 us, tolerance 512 ppm,
>  pps frequency 0.000 ppm, stability 0.000 ppm, jitter 1.000 us,
>  intervals 116977, jitter exceeded 509, stability exceeded 8, errors 532.
>
>I'm not very expert on how to assess these numbers, so can anyone give
>advices if things are working well and maybe if I can improuve
>something? Ntp version is 4.2.0 and the linux host runs 2.4.30+NANO
>kernel.
>
>Regards
>
>Francesco
>  
>
I'd say things are working very well indeed!  Solaris believes it's 
within 3 microseconds of the correct time and Linux believes it's within 
1 microsecond.   It's possible that you could improve the performance 
but I suspect that you would spend a great deal of money, time, and 
effort for very little gain.   If you insist, look at things like 
optimizing the serial port drivers and interrupt handling of both 
operating systems, upgrading to faster hardware, etc.

At 3:18 PM +0200 2005-05-20, Martin Burnicki wrote:

>  I've also seen that the ACPI implementation in a PC BIOS affects the quality
>  of time keeping. With ACPI enabled there's been some jitter in the system
>  clock, but after ACPI had been disabled by the BIOS programmers, the jitter
>  disappeared. You can't blame things like this on Linux.

	No, I'm not "blaming" those sorts of things on Linux.  However, 
when a user reports a problem of this sort, odds are more likely than 
not that they will probably be using Linux.  The problems tend to 
coincide, but there is not a causal relationship.

	If they were using FreeBSD (or one of the other *BSD operating 
systems), they would still have the same potential hardware issues, 
and they could still have similar clock speed/interrupt dropping 
issues, but then they would also be more likely to be more 
experienced with their OS and less likely to need our help, or at 
least less likely to need our help with more basic issues.

-- 
Brad Knowles, <brad@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.

Brad,

Brad Knowles wrote:

> At 3:18 PM +0200 2005-05-20, Martin Burnicki wrote:
> 
>>  I've also seen that the ACPI implementation in a PC BIOS affects the
>>  quality of time keeping. With ACPI enabled there's been some jitter in
>>  the system clock, but after ACPI had been disabled by the BIOS
>>  programmers, the jitter disappeared. You can't blame things like this on
>>  Linux.
> 
> No, I'm not "blaming" those sorts of things on Linux.  However,
> when a user reports a problem of this sort, odds are more likely than
> not that they will probably be using Linux.  The problems tend to
> coincide, but there is not a causal relationship.
> 
> If they were using FreeBSD (or one of the other *BSD operating
> systems), they would still have the same potential hardware issues,
> and they could still have similar clock speed/interrupt dropping
> issues, but then they would also be more likely to be more
> experienced with their OS and less likely to need our help, or at
> least less likely to need our help with more basic issues.

Right, that's the point.

Martin
-- 
Meinberg Funkuhren
Bad pyrmont
Germany