SNTP Client/Server questions - NTP

This is a discussion on SNTP Client/Server questions - NTP ; I've got a question about the rationale behind the SNTP RFC2030. Basically, a valid SNTP server is supposed to be sourced directly from a reference, never from a remote NTP server. We believe this is because of the lack of ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: SNTP Client/Server questions

  1. SNTP Client/Server questions

    I've got a question about the rationale behind the SNTP RFC2030.
    Basically, a valid SNTP server is supposed to be sourced directly from
    a reference, never from a remote NTP server. We believe this is
    because of the lack of sophisticated algorithms as found in NTP; e.g.
    sourcing an SNTP server from an NTP server is going to be inherently
    less accurate. Is that the gist of it, or is there other rationale as
    well?

    Also, assuming an SNTP client is doing similar to the spec and aliasing
    the server time with a calculated propagation delay, and assuming a LAN
    rather than the internet at large, can anyone give a general feel for
    how far off the client is going to be from its server?

    Finally, are those equations for round trip time and propagation delay
    in RFC2030 actually correct? They aren't what I would expect, and
    don't even seem to match each other.


  2. Re: SNTP Client/Server questions

    david.lindauer@honeywell.com wrote:
    []
    > Finally, are those equations for round trip time and propagation delay
    > in RFC2030 actually correct? They aren't what I would expect, and
    > don't even seem to match each other.


    No, they are in error.

    David



  3. Re: SNTP Client/Server questions

    >>> In article <1155648559.784059.118920@75g2000cwc.googlegroups.c om>, david.lindauer@honeywell.com writes:

    david> I've got a question about the rationale behind the SNTP RFC2030.
    david> Basically, a valid SNTP server is supposed to be sourced directly
    david> from a reference, never from a remote NTP server. We believe this is
    david> because of the lack of sophisticated algorithms as found in NTP; e.g.
    david> sourcing an SNTP server from an NTP server is going to be inherently
    david> less accurate. Is that the gist of it, or is there other rationale
    david> as well?

    Yes, to the best of my knowledge.

    david> Also, assuming an SNTP client is doing similar to the spec and
    david> aliasing the server time with a calculated propagation delay, and
    david> assuming a LAN rather than the internet at large, can anyone give a
    david> general feel for how far off the client is going to be from its
    david> server?

    It depends on how good the system clock is and how often sntp polls.

    david> Finally, are those equations for round trip time and propagation
    david> delay in RFC2030 actually correct? They aren't what I would expect,
    david> and don't even seem to match each other.

    Please see the updated/newer RFC:

    http://ntp.isc.org/Support/NTPRelatedRFCs

    H

  4. Re: SNTP Client/Server questions


    Harlan Stenn wrote:
    > >>> In article <1155648559.784059.118920@75g2000cwc.googlegroups.c om>, david.lindauer@honeywell.com writes:

    > david> Also, assuming an SNTP client is doing similar to the spec and
    > david> aliasing the server time with a calculated propagation delay, and
    > david> assuming a LAN rather than the internet at large, can anyone give a
    > david> general feel for how far off the client is going to be from its
    > david> server?
    >
    > It depends on how good the system clock is and how often sntp polls.


    thanks. We aren't looking for performance extremes... Would it be
    reasonable to get an accuracy within several seconds, feeding sntp
    clients on a lan from an sntp server which itself was fed from an NTP
    server on the net? Assuming a local clock which is nominally 60 ticks
    per second? And assuming the polls on both ends could be done often
    enough to account for local clock drifts?

    and thanks for the updated RFC...


  5. Re: SNTP Client/Server questions

    david.lindauer@honeywell.com wrote:
    > Harlan Stenn wrote:
    >
    >>>>>In article <1155648559.784059.118920@75g2000cwc.googlegroups.c om>, david.lindauer@honeywell.com writes:

    >>
    >>david> Also, assuming an SNTP client is doing similar to the spec and
    >>david> aliasing the server time with a calculated propagation delay, and
    >>david> assuming a LAN rather than the internet at large, can anyone give a
    >>david> general feel for how far off the client is going to be from its
    >>david> server?
    >>
    >>It depends on how good the system clock is and how often sntp polls.

    >
    >
    > thanks. We aren't looking for performance extremes... Would it be
    > reasonable to get an accuracy within several seconds, feeding sntp
    > clients on a lan from an sntp server which itself was fed from an NTP
    > server on the net? Assuming a local clock which is nominally 60 ticks
    > per second? And assuming the polls on both ends could be done often
    > enough to account for local clock drifts?
    >
    > and thanks for the updated RFC...
    >


    W32TIME is good enough to keep things synched up within a second or two.
    That's good enough for many applications. It seems to query a server
    somewhere between once an hour and once a week and does not place a
    heavy load on a server. If it meets your requirements, you don't need
    to do more.

    Using an SNTP client as a server is not recommended but if it works for
    you, use it. If you have doubts, it's not terribly difficult to set up
    a true NTP server although I've never done it on Windoze. I have a Sun
    Solaris system in that role.

  6. Re: SNTP Client/Server questions


    >thanks. We aren't looking for performance extremes... Would it be
    >reasonable to get an accuracy within several seconds, feeding sntp
    >clients on a lan from an sntp server which itself was fed from an NTP
    >server on the net? Assuming a local clock which is nominally 60 ticks
    >per second? And assuming the polls on both ends could be done often
    >enough to account for local clock drifts?


    That depends on how often you poll and how much your clock drifts.

    "several seconds" is a long time relative to round-trip delays to
    a nearby time server. Let's ignore those delays for now.

    Several PCs I have access to are off by slighly more than 100 ppm.
    There are 86K seconds per day. Call it 100K. So a crystal error of
    10 ppm would turn into a clock error of one second per day.

    So you would have to poll 10 times per day - once every 2 hours.

    Back to network delays. Does your link to the outside world get
    overloaded at times? That may confuse things.

    --
    The suespammers.org mail server is located in California. So are all my
    other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
    commercial e-mail to my suespammers.org address or any of my other addresses.
    These are my opinions, not necessarily my employer's. I hate spam.


  7. Re: SNTP Client/Server questions


    Hal Murray wrote:
    >
    > That depends on how often you poll and how much your clock drifts.
    >
    > "several seconds" is a long time relative to round-trip delays to
    > a nearby time server. Let's ignore those delays for now.
    >
    > Several PCs I have access to are off by slighly more than 100 ppm.
    > There are 86K seconds per day. Call it 100K. So a crystal error of
    > 10 ppm would turn into a clock error of one second per day.
    >
    > So you would have to poll 10 times per day - once every 2 hours.
    >
    > Back to network delays. Does your link to the outside world get
    > overloaded at times? That may confuse things.
    >

    yes that pretty much agrees with our notion of PC clocks... although
    some of what we get is much worse.

    Our main concern is that the clocks at the lowest tier agree with each
    other within a couple of seconds... the real time isn't quite so
    important but we are trying to get a feel for whether we can keep them
    reasonably close to the real time without a full NTP client in our part
    of the system. Reasonably close being within a few seconds, and this
    assuming there aren't local network problems with polling once an hour.


    This is just one possible configuration... there are other
    configurations we are considering some of which are more accurate than
    this and some less...


  8. Re: SNTP Client/Server questions

    Try it. If it works, great. If not, your choices include running sntp more
    often or running ntpd.

    H

  9. Re: SNTP Client/Server questions


    >Try it. If it works, great. If not, your choices include running sntp more
    >often or running ntpd.


    Another thing to consider is calibrating the drift.

    Let it run for a week or so and see how much it has drifted.
    Then do the math to figure out the fudge-factor you need.
    I think there is some program to set it, but I don't remember
    the name.

    The idea is to correct for the manufacturering error in the
    crystal. That doesn't cover temperature variations, but it
    will many a huge difference on many systems.


    --
    The suespammers.org mail server is located in California. So are all my
    other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
    commercial e-mail to my suespammers.org address or any of my other addresses.
    These are my opinions, not necessarily my employer's. I hate spam.


+ Reply to Thread