[ntp:questions] SNTP server + ntpd 4.2.4 client

Unruh unruh-spam at physics.ubc.ca
Mon Mar 17 15:51:29 UTC 2008


Noob <root at localhost> writes:

>David Woolley wrote:

>> Noob wrote:
>> 
>>> I've been running ntpd 4.2.4 to synchronize my system clock using 
>>> remote stratum 2 servers as a reference. (The RTT to these servers is 
>>> in the 30-50 ms range.) The accuracy is in the 1-2 ms range, based on 
>>> the reported offset.
>> 
>> Offset doesn't tell you the accuracy, it only gives you an idea of the 
>> variability of the error.  Theoretically, the error could be as much as 
>> 15 to 25ms, plus the error from the stratum one to the stratum 2.

>What metric should I consider to determine accuracy?

The round trip time is an upper bound on the accuracy. The problem is that
the delay can be very asymmetric-- the outbound packet could take 29ms to
get there and teh return 1ms. While unlikely, DSL for example IS
assymmetric. at the tenths of a msec range. There is no way of knowing with
ntp whether or not the trip is asymetric. Ie, while there is an upper bound
on accuracy, there is no metric which measures actual accuracy.




># ntpq -crv
>assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
>version="ntpd 4.2.4p0 at 1.1472 Fri Mar 16 10:45:43 UTC 2007 (1)",
>processor="i686", system="Linux/2.6.22.1-rt9", leap=00, stratum=2,
>precision=-20, rootdelay=46.299, rootdispersion=17.260, peer=18760,
>refid=134.226.81.3,
>reftime=cb88c64c.edb1a310  Mon, Mar 17 2008 10:28:28.928, poll=8,
>clock=cb88c77e.ef7df269  Mon, Mar 17 2008 10:33:34.935, state=4,
>offset=-0.295, frequency=-6.442, jitter=0.291, noise=0.248,
>stability=0.001

>09:07:02: offset -0.000288 sec freq -6.433 ppm error 0.000453 poll 8
>09:14:02: offset -0.000712 sec freq -6.436 ppm error 0.000431 poll 8
>09:21:02: offset -0.000551 sec freq -6.437 ppm error 0.000418 poll 8
>09:28:02: offset -0.000551 sec freq -6.437 ppm error 0.000422 poll 8
>09:35:02: offset -0.000539 sec freq -6.438 ppm error 0.000415 poll 8
>09:42:02: offset -0.000347 sec freq -6.439 ppm error 0.000856 poll 8
>09:49:02: offset -0.000389 sec freq -6.440 ppm error 0.000597 poll 8
>09:56:02: offset -0.000389 sec freq -6.440 ppm error 0.000874 poll 8
>10:03:02: offset -0.000039 sec freq -6.441 ppm error 0.000793 poll 8
>10:10:02: offset -0.000039 sec freq -6.441 ppm error 0.000402 poll 8
>10:17:02: offset -0.000039 sec freq -6.441 ppm error 0.000402 poll 8
>10:24:02: offset -0.000039 sec freq -6.441 ppm error 0.000368 poll 8
>10:31:02: offset -0.000295 sec freq -6.442 ppm error 0.000291 poll 8
>10:38:02: offset -0.000295 sec freq -6.442 ppm error 0.000167 poll 8
>10:45:02: offset -0.000295 sec freq -6.442 ppm error 0.000417 poll 8
>10:52:02: offset -0.000313 sec freq -6.443 ppm error 0.000349 poll 8
>10:59:02: offset -0.000103 sec freq -6.444 ppm error 0.000312 poll 8
>11:06:02: offset -0.000103 sec freq -6.444 ppm error 0.000285 poll 8
>11:13:02: offset -0.000103 sec freq -6.444 ppm error 0.000255 poll 8
>11:20:02: offset -0.000103 sec freq -6.444 ppm error 0.000340 poll 8

>>> I've been asked to evaluate the following time server, in order to 
>>> reach a better accuracy than what the current setup provides.
>>> 
>>> http://www.heoldesign.com/index.php?id=58
>>> 
>>> (AFAIU, this time server implements SNTP, not the full NTP.)
>> 
>> There are many network timeservers that implement full NTP, so I'm not 
>> sure what they are doing with just SNTP; maybe it is aimed at the 
>> Windows w32time market.

>Maybe they just need a clue? :-)

sorry, but using an SNTP as a server is idiotic. It is designed as a
client. Just use ntp as a server.


>> Also, you can use a GPS timing receiver, with 1 pps output, directly.

>My system is running a Linux kernel patched with real-time support.
>I don't feel confident applying the PPS support patch on top of it.

No need. Just attach the gps as a refclock. The kernel does not need pps
support to use the refclock.


>>> The idea would be to put this (stratum 1) time server in the same LAN 
>>> as my box, and add it my ntp.conf. (The RTT on the LAN is on the order 
>>> of 100 µs.)
>>>
>>> Will it work?
>> 
>> It's a violation of NTP, so the result will only be compliant as an 
>> SNTP client.

>What is a violation of NTP?

SNTP is a client protocol, not a server, according to RFC.  



>> It may or may not work, depending on whether or not early 
>> w32time implementations conformed to SNTP.  Early versions of w32time 
>> didn't set enough of the response fields to sensible values to guarantee 
>> that ntpd would work as a client.

>Why do you mention w32time?

>Do you think the HEOL-T101 is running Windows?

We have absolutely no idea what you are running on all your machines. You
never told us. This was an assumption based on the weird conditions you
stated. It really really helps if you give information when you ask for
help so that the help may actually be helpful. Tell us what your system is,
what "SNTP program" you are using as the server, what the other client
machines on the lan are running.



>>> What kind of accuracy may I expect?
>> 
>> If it works, you can probably expect most of the errors to be within 
>> your box.

>Does this mean it is reasonable to expect 100 µs accuracy?

It you attach a gps PPS receiver to one of your boxes (the server) and you
use a reasonable client then yes you can expect much better than 100us
accuracy on your net-- assuming it is not overloaded and the machines are
not overloaded with disk activity.
 


>Regards.




More information about the questions mailing list