Re: SNTP server + ntpd 4.2.4 client

Noob <root@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
ntpd.

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



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



.

Relevant Pages

  • Cannot synchronize to server with local clock
    ... fudged at a high stratum like 8 or 10. ... The *server* stratum varies from 16 ... Without sync machines will diverge. ... and another one stratum 14 on a given client. ...
    (comp.protocols.time.ntp)
  • Re: Cannot synchronize to server with local clock
    ... >> stratum 14 on a given client. ... No "prefer" on server in this case! ... The given client is not a leaf. ... not against MCT, last time I checked. ...
    (comp.protocols.time.ntp)
  • Re: Philosophical question about strata
    ... A stratum one server is stratum one because it gets its time from a primary standard; ... A server that gets its time from a WWV receiver is technically stratum one and can be several milliseconds off because of the vagaries of HF radio propagation. ... A client that is three thousand miles away from a stratum one server and receiving time over a heavily used network is probably getting time that is an order of magnitude poorer than a client three hundred feet away. ...
    (comp.protocols.time.ntp)
  • Re: Philosophical question about strata
    ... Suppose you have two ntp clients that get their time from multiple ... You can use one of the stratum 1 servers, ... It seems to me that the right choice is the stratum 2 server. ... if you configure this new client so that it uses one stratum 1 ...
    (comp.protocols.time.ntp)
  • Why do clients reject win 2003 ntp server?
    ... You appear to have a stratum one server on your private network, ... can't be using W32Time, as that is a SNTP server and using ...
    (comp.protocols.time.ntp)