SNTP server + ntpd 4.2.4 client - NTP

This is a discussion on SNTP server + ntpd 4.2.4 client - NTP ; Hello, 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 ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 56

Thread: SNTP server + ntpd 4.2.4 client

  1. SNTP server + ntpd 4.2.4 client

    Hello,

    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.

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

    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?

    Is it a problem that the time server only implements SNTP?

    What kind of accuracy may I expect?

    Regards.

  2. Re: SNTP server + ntpd 4.2.4 client

    Noob wrote:
    > Hello,
    >
    > 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.
    >
    > 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
    >


    That link takes me to a page advertising THREE products! Which one did
    you have in mind?

    > (AFAIU, this time server implements SNTP, not the full NTP.)
    >
    > 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 should work.

    > Is it a problem that the time server only implements SNTP?
    >


    It should not be a problem. The largest difference between NTP and SNTP
    is the effort to account for the vagaries of the internet!

    > What kind of accuracy may I expect?
    >


    These devices should be accurate to within the range of 25 to 100
    nanoseconds. The limiting factor will be the jitter introduced while
    getting the time into your computer.

    A SWAG (Scientific Wild Ass Guess) would be 500 microseconds. By
    spending a lot of time and effort you might be able to get something
    better than that. The chief difficulty would be measuring and
    controlling the delays within the computer.






  3. Re: SNTP server + ntpd 4.2.4 client

    Richard B. Gilbert 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.
    >>
    >> 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

    >
    > That link takes me to a page advertising THREE products! Which one did
    > you have in mind?


    The HEOL-T101 (with a Fast Ethernet port).

    >> Is it a problem that the time server only implements SNTP?

    >
    > It should not be a problem. The largest difference between NTP and SNTP
    > is the effort to account for the vagaries of the internet!


    Cool. (I'll give RFC 4330 a look.)

    >> What kind of accuracy may I expect?

    >
    > These devices should be accurate to within the range of 25 to 100
    > nanoseconds.


    The spec seems to mention +/- 40 ns.

    > The limiting factor will be the jitter introduced while
    > getting the time into your computer.


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

    > A SWAG (Scientific Wild Ass Guess) would be 500 microseconds. By
    > spending a lot of time and effort you might be able to get something
    > better than that. The chief difficulty would be measuring and
    > controlling the delays within the computer.


    I thought the error was on the order of half the RTT, i.e. I could
    hope for 40-50 Ás in my situation?

    Regards.

  4. Re: SNTP server + ntpd 4.2.4 client

    Noob wrote:

    > I'll give RFC 4330 a look.


    http://tools.ietf.org/html/rfc4330

    David Mills wrote:

    "SNTP servers should operate only at the root (stratum 1) of the
    subnet, and then only in configurations where no other source of
    synchronization other than a reliable radio clock or telephone modem
    is available."

    Is a GPS receiver considered a reliable radio clock?

    Regards.

  5. Re: SNTP server + ntpd 4.2.4 client

    Noob wrote:
    > Richard B. Gilbert 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.
    >>>
    >>> 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

    >>
    >>
    >> That link takes me to a page advertising THREE products! Which one
    >> did you have in mind?

    >
    >
    > The HEOL-T101 (with a Fast Ethernet port).
    >
    >>> Is it a problem that the time server only implements SNTP?

    >>
    >>
    >> It should not be a problem. The largest difference between NTP and
    >> SNTP is the effort to account for the vagaries of the internet!

    >
    >
    > Cool. (I'll give RFC 4330 a look.)
    >
    >>> What kind of accuracy may I expect?

    >>
    >>
    >> These devices should be accurate to within the range of 25 to 100
    >> nanoseconds.

    >
    >
    > The spec seems to mention +/- 40 ns.
    >
    >> The limiting factor will be the jitter introduced while getting the
    >> time into your computer.

    >
    >
    > I plan to connect my box to the time server using a cross-over cable.
    > (My box has 4 Ethernet ports, I will devote one to NTP traffic.) The RTT
    > is very stable at 80-85 Ás.
    >
    >> A SWAG (Scientific Wild Ass Guess) would be 500 microseconds. By
    >> spending a lot of time and effort you might be able to get something
    >> better than that. The chief difficulty would be measuring and
    >> controlling the delays within the computer.

    >
    >
    > I thought the error was on the order of half the RTT, i.e. I could hope
    > for 40-50 Ás in my situation?
    >
    > Regards.


    Given the above, you are correct, 40-50 microseconds. I had assumed
    that you were using a serial port where the latencies are greater.


  6. Re: SNTP server + ntpd 4.2.4 client

    Noob wrote:
    > Noob wrote:
    >
    >> I'll give RFC 4330 a look.

    >
    >
    > http://tools.ietf.org/html/rfc4330
    >
    > David Mills wrote:
    >
    > "SNTP servers should operate only at the root (stratum 1) of the subnet,
    > and then only in configurations where no other source of synchronization
    > other than a reliable radio clock or telephone modem is available."
    >
    > Is a GPS receiver considered a reliable radio clock?


    Yes.



  7. Re: SNTP server + ntpd 4.2.4 client

    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.

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

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

    >
    > 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 you the result will only be compliant as an
    SNTP client. 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.


    >
    > Is it a problem that the time server only implements SNTP?
    >
    > What kind of accuracy may I expect?


    If it works, you can probably expect most of the errors to be within
    your box.

  8. Re: SNTP server + ntpd 4.2.4 client

    David Woolley writes:

    >Noob wrote:
    >>=20
    >> I've been running ntpd 4.2.4 to synchronize my system clock using remot=

    >e=20
    >> stratum 2 servers as a reference. (The RTT to these servers is in the=20
    >> 30-50 ms range.) The accuracy is in the 1-2 ms range, based on the=20
    >> reported offset.


    >Offset doesn't tell you the accuracy, it only gives you an idea of the=20
    >variability of the error. Theoretically, the error could be as much as=20
    >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 moere
    than inbound packets for example) and your clock would be biased.

    It is highly unlikely that packets take zero time to go out and 50ms to get
    back however.



    >>=20
    >> I've been asked to evaluate the following time server, in order to reac=

    >h=20
    >> a better accuracy than what the current setup provides.


    You are not going to get better accuracy by changing ntp program (well the
    evidence is that chrony is a somewhat better client, but in your case the
    difference will be negligible) . 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)

    going to get better accuracy
    >>=20
    >> http://www.heoldesign.com/index.php?id=3D58
    >>=20
    >> (AFAIU, this time server implements SNTP, not the full NTP.)


    Then it is not a server.


    >There are many network timeservers that implement full NTP, so I'm not=20
    >sure what they are doing with just SNTP; maybe it is aimed at the=20
    >Windows w32time market.


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


    Yes. IF you want better accuracy, get yourself a Garmin 18LVC, wire it up
    and use the PPM output. They you will have a few microsecond accuracy. YOu
    will never get your network ntp under a few ms.



    >>=20
    >> The idea would be to put this (stratum 1) time server in the same LAN a=

    >s=20
    >> 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.
    It you attach a GPS to one of your (Linux) machines, you will get 2usec
    accuracy on that machine. On the machines attached on your lan yyou will
    get 10s of usec accuracy, if they are unix type machines. 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.



    >> 100 =B5s.)
    >>=20
    >> Will it work?


    >It's a violation of NTP, so you the result will only be compliant as an=20
    >SNTP client. It may or may not work, depending on whether or not early=20
    >w32time implementations conformed to SNTP. Early versions of w32time=20
    >didn't set enough of the response fields to sensible values to guarantee =


    >that ntpd would work as a client.



    >>=20
    >> Is it a problem that the time server only implements SNTP?
    >>=20
    >> What kind of accuracy may I expect?


    >If it works, you can probably expect most of the errors to be within=20
    >your box.


  9. Re: SNTP server + ntpd 4.2.4 client

    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?

    # ntpq -crv
    assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
    version="ntpd 4.2.4p0@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? :-)

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

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

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

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

    Regards.

  10. Re: SNTP server + ntpd 4.2.4 client

    Hello Bill,

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

    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.

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

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

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

    > 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

    Regards.

  11. Re: SNTP server + ntpd 4.2.4 client

    Noob wrote:

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


    You cannot measure that using ntpd itself. If you really need to know
    the accuracy, you must measure the true time with something with lower
    error bounds and compare.

    The error should be somewhere within about +/- (rootdelay/2 +
    rootdispersion + jitter), if I remember correctly. Most of the time it
    will be much better than this, but you need to know the limits of
    asymmetry in your network round trip time and the worst case frequency
    errors, if you want a better figure.

    The basic problem is that, if ntpd knew the error, it would compensate
    for it and that part of the error would no longer be part of the error!

    With your figures, I would guess that the rootdispersion contribution is
    low, so the real question is how much propagation delay asymmetry there is.

    >> It's a violation of NTP, so the result will only be compliant as an
    >> SNTP client.

    >
    > What is a violation of NTP?


    NTP clients must use NTP servers, not SNTP ones.

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


    Because w32time claims to be SNTP and I've seen cases where ntpd will
    refuse to synchronise to it because it is reporting error metrics that
    exceed maximums, even though it has got an upstream time source. (If I
    remember correctly, it was reflecting those in the request.)

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


    It's running SNTP and w32time is the most commonly encountered
    implementation claiming to be SNTP, these days, so w32time is a model of
    what can go wrong when using SNTP.

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


    For ethernet communicated time, one typically expects 1ms to 2ms.
    However, you need to know network loading (a properly dimensioned
    ethernet will have significant latency due to contention) and interrupt
    and process scheduling latencies on both sides.

  12. Re: SNTP server + ntpd 4.2.4 client

    Noob wrote:
    > Hello Bill,
    >
    > (Your news client often adds an extraneous =20 suffix to quotes.)


    That happens when you reply to a MIME Quoted-Printable posting that has
    trailing spaces, using a user agent that doesn't understand MIME. Mine
    will have trailing spaced so that suitable clients will treat the
    newline as soft, and ones that don't will insert a newline at a sensible
    position. (Many GUI user agents try to put whole paragraphs on one
    line, which is simply broken.

  13. Re: SNTP server + ntpd 4.2.4 client

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


  14. Re: SNTP server + ntpd 4.2.4 client

    Unruh wrote:
    > Noob 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@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.

    >


    If you REALLY want to determine the accuracy of NTP, get yourself a
    Cesium Clock, have it calibrated by your national standdards lab, and
    then measure your error.

    If you think that's too much trouble, you're probably right!!


  15. Re: SNTP server + ntpd 4.2.4 client

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




  16. Re: SNTP server + ntpd 4.2.4 client

    Unruh wrote:

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


    Is section 6 in RFC 4330 a figment of my imagination then?

    http://tools.ietf.org/html/rfc4330#section-6

  17. Re: SNTP server + ntpd 4.2.4 client

    Unruh wrote:
    >> 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 Linux kernel does not have built-in PPS support, so yes he would have to
    patch and recompile the kernel in order to use the PPS provided by the GPS
    device. Otherwise it will just be using NMEA time, which is not very
    accurate for timing purposes. For Linux 2.4 there is the PPSkit, and for
    Linux 2.6 there is LinuxPPS.

    Instead you can use the shmpps driver to use the PPS signal without patching
    the Linux kernel. I use it and it works very well.

    FreeBSD has built-in PPS support (no patch needed), but it's not enabled by
    default. PPS support has to be enabled in the kernel config and the kernel
    recompiled.

    Dennis

    --
    Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com
    NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php

  18. Re: SNTP server + ntpd 4.2.4 client

    "Dennis Hilberg, Jr." writes:

    >Unruh wrote:
    >>> 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 Linux kernel does not have built-in PPS support, so yes he would have to
    >patch and recompile the kernel in order to use the PPS provided by the GPS
    >device. Otherwise it will just be using NMEA time, which is not very
    >accurate for timing purposes. For Linux 2.4 there is the PPSkit, and for
    >Linux 2.6 there is LinuxPPS.


    >Instead you can use the shmpps driver to use the PPS signal without patching
    >the Linux kernel. I use it and it works very well.


    Precisely. As I said, your kernel does not need pps support to use the
    refclock. I also use it and it works well. (well, I actually modified it,
    so I have a purpose built interrupt service routine to service the parallel
    port interrupt and read the clock. The shmpps then reads those times, and
    sends them to ntp. A bit of a rube goldberg but it works.
    I like the parallel port interrupt better than the serial but am not sure
    why.






    >FreeBSD has built-in PPS support (no patch needed), but it's not enabled by
    >default. PPS support has to be enabled in the kernel config and the kernel
    >recompiled.


    And exactly what is that supposed to buy you?
    You need something which can be interrupted by the pps signal from the gps,
    and read the system time on that interrupt. That does not require kernel
    support (except of course being able to respond to interrupts-- and if your
    kernel cannot do that, you forgot to switch on your computer.)


    >Dennis


    >--
    >Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com
    >NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php


  19. Re: SNTP server + ntpd 4.2.4 client

    >>> In article <47de7007$0$636$5a6aecb4@news.aaisp.net.uk>, David Woolley writes:

    David> NTP clients must use NTP servers, not SNTP ones.

    I do not believe this is true.

    The problem is one might want to *know* that the SNTP server is actually
    talking to a refclock, or more generally, that the SNTP "instance" is
    playing by the rules.

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  20. Re: SNTP server + ntpd 4.2.4 client

    Unruh wrote:
    >> FreeBSD has built-in PPS support (no patch needed), but it's not enabled by
    >> default. PPS support has to be enabled in the kernel config and the kernel
    >> recompiled.

    >
    > And exactly what is that supposed to buy you?
    > You need something which can be interrupted by the pps signal from the gps,
    > and read the system time on that interrupt. That does not require kernel
    > support (except of course being able to respond to interrupts-- and if your
    > kernel cannot do that, you forgot to switch on your computer.)


    If I understand correctly, it allows the kernel to discipline the local
    clock directly from the PPS signal, instead of having a separate helper
    program like shmpps pass it to a shared memory segment for ntpd to handle,
    which will discipline the clock via the SHM driver. I don't know if one
    method is better as I've tried both and there didn't seem to be much
    difference as far as I could tell. But at the least having PPS support
    enabled allows you to use the type 20 (generic NMEA GPS receiver) driver
    which will deal with both the PPS and NMEA time. That would eliminate both
    the need to have upstream servers for time sources as well as the separate
    helper program. However, most timekeepers will (should) have a few upstream
    servers for sanity checks anyway, and most systems nowadays can easily
    handle a small driver like shmpps running all the time.

    Dennis

    --
    Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com
    NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast