[ntp:questions] SNTP server + ntpd 4.2.4 client

Unruh unruh-spam at physics.ubc.ca
Mon Mar 17 16:01:43 UTC 2008

Noob <root at localhost> writes:

>Hello Bill,

>(Your news client often adds an extraneous =20 suffix to quotes.)

Nope, that is your new client. Mine is a primative ascii based client which
just reports what it sees. No special encoding is needed for a blank.

>Bill Unruh wrote:

>> 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.
>> Agreed. The accuracy is bounded by the round trip time. The offset
>> fluctuations will give and estimate of those variations in round trip time.
>> But that time could be biased (ie outbound packets always take 10ms more
>> than inbound packets for example) and your clock would be biased.

>Point taken.

>>>> I've been asked to evaluate the following time server, in order to reach
>>>> a better accuracy than what the current setup provides.
>> You are not going to get better accuracy by changing ntp program

>You have apparently misread my original post. I do not plan to change 

>> You are going to get a better time by using a server that is closer to
>> you and has more predictable round trip times (ethernet, not ADSL)

>This is precisely what I plan to do. Specifically, I plan to connect 
>my box to the time server using a cross-over Ethernet cable. (My box 
>has 4 gigabit Ethernet ports, I will devote one to NTP traffic.) The 
>RTT is very stable at 80-85 µs.

That does not help if the server does not have good time. Where does it
gets its time from?

>>>> (AFAIU, this time server implements SNTP, not the full NTP.)
>> Then it is not a server.

>I don't understand the point you are trying to make.
>It is an SNTP server.

AFAIK, SNTP is a CLIENT protocol, not a server. That is why it is called

>> You will never get your network ntp under a few ms.

>Unless the stratum 1 server is on the same LAN...
>(As you state later.)

No unless your server is disciplined by an attached refclock or by a very
nearby 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
>> It is NOT a stratum 1.
>> A stratum 1 gets its time from an atomic clock.

>I don't understand the point you are trying to make.

>The time server has a GPS receiver, thus it is "attached" to a
>stratum 0 device, thus it is a stratum 1 server.

An SNTP server which is attached to a GPS? What are you running? What IS
this SNTP software?
IF you have a true Stratum 1 as you describe, then yes, you can get 10usec
accuracy on your clients. 

>> If you attach a GPS to one of your (Linux) machines, you will get 2 µs
>> accuracy on that machine. On the machines attached on your LAN you will
>> get 10s of µs accuracy, if they are unix type machines.

>This is the setup I've been discussing, with the GPS receiver inside 
>the "time server" I'm supposed to evaluate...

>> As far as I know
>> windows does not impliment a proper clock control API so you will have be
>> happy with a few msec for those.

>I should have made clear that I am not using Windows.
>The system to be synchronized runs Linux and ntpd 4.2.4

What does the system you are evaluating run? 
To evaluate it, buy a Garmin GPS18LVC wire it up, place it onto the client,
and have a parallel port interrupt routine read the times of the PPS input
connected to the parallel port. That will be good to 2usec or so. Then you
can see how accurate the discipline by the evaluated receiver is. There is
absolutely no way of evaluating a timeclock on its own. It could be 7 ms
out and you would have no way of knowing. 

More information about the questions mailing list