NTP client basic - NTP

This is a discussion on NTP client basic - NTP ; Greetings to the list: I am an amateur programmer and a radio amateur. 18 months ago I needed to closely control the clock on my PC for a radio-monitoring application, and wrote an NTP synchroniser with Delphi, using an NTP ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: NTP client basic

  1. NTP client basic

    Greetings to the list:

    I am an amateur programmer and a radio amateur. 18 months ago I needed to
    closely control the clock on my PC for a radio-monitoring application, and
    wrote an NTP synchroniser with Delphi, using an NTP component I found on the
    internet. It's been running perfectly since then, keeping the clock within
    10mS rms.

    Recently a friend in another part of Europe wanted to do the same, so I sent
    him my effort. To my surprise it went crazy, tweeking the clock to crazy
    times and rates, and locking itself up.

    To cut a long story short, I discovered that there were duplicate NTP
    requests reaching the server, and the duplicate replies were getting
    mixed-up. I dug deep into the source code of the NTP component, and although
    I couldn't find the cause of the duplicates, I realised the thing was not
    well written and would malfunction if it encountered a repeat NTP reply. I
    wrote my own, working from RFC2030 and using a Delphi UDP component.

    That suffered the same problem. I now know that the UDP protocol which
    underlies NTP, is NOT guaranteed to prevent duplicates. I therefore had to
    take steps in my code to detect and suppress them. The NTP client component
    I had used previously had taken no account of this. RFC2030 only hints at
    the problem. I am amazed.

    My questions are therefore:
    1) Do ALL good NTP clients take steps to suppress duplicate requests and/or
    replies, or do they survive by assuming that they don't occur very often? My
    original survived 18 months without being hit, but my friend in Belgium was
    hit by 1 repeat in 1000 or so, which rendered the NTP process unusable.

    2) Knowing that the UDP protocol can produce spurious repeats, I would have
    thought the NTP server could detect them and suppress the repeated replies.
    Do they do this or am I being naive?

    3) Does anyone have any figures for the incidence of UDP repeats? What sort
    of delay would one expect between the original and the repeat? I am seeing
    figures of 5 minutes or more, which really surprises me. Maybe my friend
    has a particularly noisy ADSL connection.

    4) What's the usual way of suppressing duplicate replies? Comparing a local
    copy of the request's xmit timestamp with the reply's orig. timestamp seems
    the obvious.

    If these questions have come to the wrong place, would some kind soul point
    it (or me) in a better direction.

    Thanks.

    Peter Martinez
    NorthWest UK.

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: NTP client basic

    Peter Martinez wrote:
    > Greetings to the list:
    >
    > I am an amateur programmer and a radio amateur. 18 months ago I
    > needed to closely control the clock on my PC for a radio-monitoring
    > application, and wrote an NTP synchroniser with Delphi, using an NTP
    > component I found on the internet. It's been running perfectly since
    > then, keeping the clock within 10mS rms.

    []
    > If these questions have come to the wrong place, would some kind soul
    > point it (or me) in a better direction.
    >
    > Thanks.
    >
    > Peter Martinez
    > NorthWest UK.


    Peter,

    I believe these questions are on-topic here.

    I also wrote some NTP code using Delphi, and was fortunate enough not to
    encounter the problem you mentioned. Indeed, the XMIT timestamp is what
    could be used to confirm the reply.

    However, you didn't need to write any code at all, since the full NTP
    implementation is already available for Windows:

    http://www.meinberg.de/english/sw/ntp.htm

    and capable of excellent performance, even on my loaded systems:

    http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html

    (These could do even better if I reduced the polling interval). I also
    made a simple GPS interface for my local reference:

    http://www.david-taylor.myby.co.uk/n...SD-GPS-PPS.htm

    I have often read about and admired your work.

    73,
    David GM8ARV



  3. Re: NTP client basic

    In article <017a01c75c3b$15cb2850$0300a8c0@LAPTOP>
    peter.martinez@btinternet.com (Peter Martinez) writes:
    >
    >To cut a long story short, I discovered that there were duplicate NTP
    >requests reaching the server, and the duplicate replies were getting
    >mixed-up. I dug deep into the source code of the NTP component, and although
    >I couldn't find the cause of the duplicates, I realised the thing was not
    >well written and would malfunction if it encountered a repeat NTP reply. I
    >wrote my own, working from RFC2030 and using a Delphi UDP component.


    RFC 2030 does not describe NTP, but the in comparison very limited SNTP,
    and it does mention a number of caveats on the use of SNTP.

    >That suffered the same problem. I now know that the UDP protocol which
    >underlies NTP, is NOT guaranteed to prevent duplicates. I therefore had to
    >take steps in my code to detect and suppress them. The NTP client component
    >I had used previously had taken no account of this. RFC2030 only hints at
    >the problem. I am amazed.
    >
    >My questions are therefore:
    >1) Do ALL good NTP clients take steps to suppress duplicate requests and/or
    >replies, or do they survive by assuming that they don't occur very often? My
    >original survived 18 months without being hit, but my friend in Belgium was
    >hit by 1 repeat in 1000 or so, which rendered the NTP process unusable.


    NTP specifies sophisticated filtering algorithms that will cause all
    "oddball" responses to be effectively ignored, there's no reason to take
    the possibility of duplicate replies into special consideration. SNTP
    does not do so, but I guess there is a (reasonable) assumption that
    anyone implementing it will include at least basic sanity checks on the
    packets received - and 2030 *does* mention this, even if you think it's
    just a "hint". Believing a single packet that says that your time is 5
    minutes off is not a good idea, regardless of the issue of duplicates -
    and if the roundtrip calculation gives a result of the same magnitude,
    that's of course a further indication that it should just be tossed.

    >2) Knowing that the UDP protocol can produce spurious repeats, I would have
    >thought the NTP server could detect them and suppress the repeated replies.
    >Do they do this or am I being naive?


    No, that would require a server to keep state for every client, which is
    not desirable - it's up to the client to deal with the responses it
    gets.

    >3) Does anyone have any figures for the incidence of UDP repeats? What sort
    >of delay would one expect between the original and the repeat? I am seeing
    >figures of 5 minutes or more, which really surprises me. Maybe my friend
    >has a particularly noisy ADSL connection.


    I don't have any numbers, but I would say that duplicates are extremely
    rare, and probably always indicate faulty or misconfigured network
    equipment. After all *something* must have transmitted the packet twice,
    which is always the Wrong Thing to do for UDP. One case I can think of
    would be a setup with Ethernet half/full duplex mismatch - a sender that
    believes that the link is half duplex will see "false collisions" and
    retransmit (at the Ethernet level), while the recipient operating in
    full duplex mode may actually have received the packet just fine.

    Of course this could not by itself result in a 5 minute delay - in fact
    I have hard time coming up with anything other than intentionally
    malicious acts that would. And this is certainly not a possibilty that
    should be ignored.

    >4) What's the usual way of suppressing duplicate replies? Comparing a local
    >copy of the request's xmit timestamp with the reply's orig. timestamp seems
    >the obvious.


    Yes, this is a good sanity check. I don't know if it's "usual" since I
    haven't studied the implementation of any SNTP clients. For NTP it's a
    non-issue per above, and even some rudimentary filtering in the SNTP
    case would have taken care of your problem - e.g. send (say) three
    packets (adequately spaced) and use the average after tossing any
    replies that are way off.

    --Per Hedeland
    per@hedeland.org

  4. Re: NTP client basic

    In article per@hedeland.org (Per Hedeland) writes:
    >In article <017a01c75c3b$15cb2850$0300a8c0@LAPTOP>
    >peter.martinez@btinternet.com (Peter Martinez) writes:
    >>
    >>4) What's the usual way of suppressing duplicate replies? Comparing a local
    >>copy of the request's xmit timestamp with the reply's orig. timestamp seems
    >>the obvious.

    >
    >Yes, this is a good sanity check. I don't know if it's "usual" since I
    >haven't studied the implementation of any SNTP clients. For NTP it's a
    >non-issue per above, and even some rudimentary filtering in the SNTP
    >case would have taken care of your problem - e.g. send (say) three
    >packets (adequately spaced) and use the average after tossing any
    >replies that are way off.


    Addendum: The fact that your program even received the "late duplicate"
    packets implies that it holds the UDP socket open continuously (which of
    course implies that the program is running continuously). I think it's
    pretty much an (unstated) assumption that SNTP clients would operate in
    more of a one-shot mode, e.g. some OS service like Unix' 'crontab' fires
    up the program at pre-set intervals, where it does its thing and exits.

    In this case you're pretty much guaranteed that duplicates will be
    dropped by the TCP/IP stack, since there's no program listening for them
    when they arrive - or at worst that they will sit unprocessed in the
    socket input queue when the program exits, and so get dropped anyway.
    If you want your program to run continously, you can of course achieve
    the same result by opening a new socket whenever you're about to send
    (a) request(s), and close it when you're done receiving the reply/ies.

    --Per Hedeland
    per@hedeland.org

  5. Re: NTP client basic

    Peter Martinez wrote:
    > Greetings to the list:
    >
    > I am an amateur programmer and a radio amateur. 18 months ago I needed to
    > closely control the clock on my PC for a radio-monitoring application, and
    > wrote an NTP synchroniser with Delphi, using an NTP component I found on the
    > internet. It's been running perfectly since then, keeping the clock within
    > 10mS rms.
    >


    What exactly do you mean by an NTP synchroniser? Is this just an NTP
    client running on your system and just taking the received time and
    using it to set the clock, does it adjust the clock frequency? What is
    it doing? Also to you have an NTP server running on this system
    separately from your NTP synchroniser?

    > Recently a friend in another part of Europe wanted to do the same, so I sent
    > him my effort. To my surprise it went crazy, tweeking the clock to crazy
    > times and rates, and locking itself up.
    >
    > To cut a long story short, I discovered that there were duplicate NTP
    > requests reaching the server, and the duplicate replies were getting
    > mixed-up. I dug deep into the source code of the NTP component, and although
    > I couldn't find the cause of the duplicates, I realised the thing was not
    > well written and would malfunction if it encountered a repeat NTP reply. I
    > wrote my own, working from RFC2030 and using a Delphi UDP component.
    >


    When you say they are duplicate requests and duplicate replies what
    exactly do you mean by that? In what way are they duplicate? In what way
    do they get mixed up?

    > That suffered the same problem. I now know that the UDP protocol which
    > underlies NTP, is NOT guaranteed to prevent duplicates. I therefore had to
    > take steps in my code to detect and suppress them. The NTP client component
    > I had used previously had taken no account of this. RFC2030 only hints at
    > the problem. I am amazed.


    UDP won't retry a packet. Either it reaches its destination or it
    doesn't. If it's being sent out again then it's in your own code.

    >
    > My questions are therefore:
    > 1) Do ALL good NTP clients take steps to suppress duplicate requests and/or
    > replies, or do they survive by assuming that they don't occur very often? My
    > original survived 18 months without being hit, but my friend in Belgium was
    > hit by 1 repeat in 1000 or so, which rendered the NTP process unusable.


    It's most likely in your own code but it's hard to tell without seeing
    it. What does it do when it doesn't receive a response for example?

    > 2) Knowing that the UDP protocol can produce spurious repeats, I would have
    > thought the NTP server could detect them and suppress the repeated replies.
    > Do they do this or am I being naive?


    No, UDP makes no attempt to repeat, spurious or otherwise. If it fails,
    it fails. UDP does nothing about it.

    > 3) Does anyone have any figures for the incidence of UDP repeats? What sort
    > of delay would one expect between the original and the repeat? I am seeing
    > figures of 5 minutes or more, which really surprises me. Maybe my friend
    > has a particularly noisy ADSL connection.


    zero.

    > 4) What's the usual way of suppressing duplicate replies? Comparing a local
    > copy of the request's xmit timestamp with the reply's orig. timestamp seems
    > the obvious.
    >


    Then your code must be sending out duplicates. Why is it doing that?

    > If these questions have come to the wrong place, would some kind soul point
    > it (or me) in a better direction.
    >


    This is the right place.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  6. Re: NTP client basic

    >From Peter Martinez:

    Per: Thanks for your remarks. I see that I should have written "SNTP"
    instead of "NTP" wherever this appears in my original posting. When I
    encountered this problem initially, the third-party SNTP client package I
    had used did indeed have the socket open continuously but only read it after
    sending a request, so if there had been a spurious reply earlier, it would
    thereafter read the reply to it's previous request! On seeing that it did
    this, I realised it was badly written, ditched it, and wrote my own, half
    hoping that this would also stop the repeats themselves (which in any case
    only show up in Belgium!)

    When the repeats still appeared in my own SNTP client implementation (now
    trapped, but logged), it seemed to me that I might have stumbled on a
    possible source of trouble. RFC2030 didn't seem to say that you MUST take
    steps to discard repeats which COULD arise in the underlying UDP protocol,
    it seemed to be saying that you could keep an eye on the xmit timestamp in
    the request - but it's not essential. RFC768 (which describes UDP) doesn't
    shed any light on whether a corrupted UDP packet could be repeated.

    That's the only reason for raising the topic. I don't need any more help to
    achieve my own objective. I am just puzzled by what I see might be a flaw.

    Peter M

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  7. Re: NTP client basic

    Peter,

    I don't understand these "duplicate" packaets.

    What is sending them? The packets are probably not being duplicated in the
    network.

    H

  8. Re: NTP client basic

    >When the repeats still appeared in my own SNTP client implementation (now
    >trapped, but logged), it seemed to me that I might have stumbled on a
    >possible source of trouble. RFC2030 didn't seem to say that you MUST take
    >steps to discard repeats which COULD arise in the underlying UDP protocol,
    >it seemed to be saying that you could keep an eye on the xmit timestamp in
    >the request - but it's not essential. RFC768 (which describes UDP) doesn't
    >shed any light on whether a corrupted UDP packet could be repeated.


    It's possible but very very unlikely for the network to duplicate
    a packet.

    Is your code retransmitting if you don't get an answer? If so, a
    likely explanation is that you aren't waiting long enough. In
    any case, your code should filter out duplicates and/or process
    them correctly.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  9. Re: NTP client basic

    In article <014301c75d93$aa58a3e0$0300a8c0@LAPTOP>
    peter.martinez@btinternet.com (Peter Martinez) writes:
    >
    >When the repeats still appeared in my own SNTP client implementation (now
    >trapped, but logged), it seemed to me that I might have stumbled on a
    >possible source of trouble. RFC2030 didn't seem to say that you MUST take
    >steps to discard repeats which COULD arise in the underlying UDP protocol,
    >it seemed to be saying that you could keep an eye on the xmit timestamp in
    >the request - but it's not essential. RFC768 (which describes UDP) doesn't
    >shed any light on whether a corrupted UDP packet could be repeated.


    UDP the protocol will *never* retransmit - since there are no acks in
    the protocol, there's simply no basis for deciding to retransmit
    anything. And since duplicates just "shouldn't happen", it wouldn't
    really make sense for the (S)NTP spec to say specifically that they must
    be ignored - should they occur after all, discarding them falls under
    general "sanity check" procedure.

    As I wrote, if you are actually seeing duplicates (and as others have
    pointed out, there could be other explanations), it's most likely due to
    faulty/misconfigured network equipment, or it could be someone actively
    sending them in an (apparently successful) attempt to disrupt your
    timekeeping. Whatever it is that is causing them, it isn't UDP.

    >That's the only reason for raising the topic. I don't need any more help to
    >achieve my own objective. I am just puzzled by what I see might be a flaw.


    Well, my elaboration was only in part meant to suggest how you could
    avoid the problem - it was just as much an attempt to explain why
    duplicates aren't an issue in the unlikely event that they actually do
    occur.

    --Per Hedeland
    per@hedeland.org

  10. Re: NTP client basic

    Peter Martinez wrote:
    >>From Peter Martinez:

    >
    > Per: Thanks for your remarks. I see that I should have written "SNTP"
    > instead of "NTP" wherever this appears in my original posting. When I
    > encountered this problem initially, the third-party SNTP client package I
    > had used did indeed have the socket open continuously but only read it after
    > sending a request, so if there had been a spurious reply earlier, it would
    > thereafter read the reply to it's previous request! On seeing that it did
    > this, I realised it was badly written, ditched it, and wrote my own, half
    > hoping that this would also stop the repeats themselves (which in any case
    > only show up in Belgium!)
    >
    > When the repeats still appeared in my own SNTP client implementation (now
    > trapped, but logged), it seemed to me that I might have stumbled on a
    > possible source of trouble. RFC2030 didn't seem to say that you MUST take
    > steps to discard repeats which COULD arise in the underlying UDP protocol,
    > it seemed to be saying that you could keep an eye on the xmit timestamp in
    > the request - but it's not essential. RFC768 (which describes UDP) doesn't
    > shed any light on whether a corrupted UDP packet could be repeated.
    >
    > That's the only reason for raising the topic. I don't need any more help to
    > achieve my own objective. I am just puzzled by what I see might be a flaw.
    >



    My, limited, understanding of UDP is that there is NO guarantee of
    delivery; a packet is sent and it either gets to its destination or not.
    The protocol does not know or care if the packet reached its
    destination. You certainly should NOT retransmit if you don't get a
    reply. The packet is stale and almost completely useless by the time
    you can be sure you will not get a reply. Send a FRESH packet with a
    new originate time stamp. UDP doesn't do error checking or retransmits
    either.

    Don't keep hammering away at a server that does not reply! It won't
    help and it just clutters up the network. See, for example:
    http://www.nanog.org/mtg-0310/pdf/plonka.pdf
    for an extreme case! It will be many years before the NTP world forgets
    this one. You DON'T want to become famous this way! ;-)

    The right ways to handle a non responsive server are to either give up
    or to double your poll interval after each N consecutive failures. You
    can stop doubling when you hit MAXPOLL; a poll every 1024 seconds (about
    17 minutes) is not going to break anybody's network.

    If you are receiving consecutive packets with identical time stamps from
    a server, consider it broken!


  11. Re: NTP client basic

    Also,

    As I recall SNTP may send out a bunch of requests but then it believes the
    first answer it gets. Any other answers should just be dropped.

    You should also be able to compare your transmit time to the transmit time
    in the return answers and throw away ones that don't match.

    The spec should have a much better list of "how to handle packets".

    H

  12. Re: NTP client basic

    Peter,

    The NTP on-wire protocol is inherently resistent to lost and duplicate
    packets. See RFC 1305 for the definitive NTPv3 defenses. These defenses
    continue in the current NTPv4. What articles you might find floating on
    the web might or might not understand how these defenses work.

    Dave

    Peter Martinez wrote:
    > Greetings to the list:
    >
    > I am an amateur programmer and a radio amateur. 18 months ago I needed to
    > closely control the clock on my PC for a radio-monitoring application, and
    > wrote an NTP synchroniser with Delphi, using an NTP component I found on the
    > internet. It's been running perfectly since then, keeping the clock within
    > 10mS rms.
    >
    > Recently a friend in another part of Europe wanted to do the same, so I sent
    > him my effort. To my surprise it went crazy, tweeking the clock to crazy
    > times and rates, and locking itself up.
    >
    > To cut a long story short, I discovered that there were duplicate NTP
    > requests reaching the server, and the duplicate replies were getting
    > mixed-up. I dug deep into the source code of the NTP component, and although
    > I couldn't find the cause of the duplicates, I realised the thing was not
    > well written and would malfunction if it encountered a repeat NTP reply. I
    > wrote my own, working from RFC2030 and using a Delphi UDP component.
    >
    > That suffered the same problem. I now know that the UDP protocol which
    > underlies NTP, is NOT guaranteed to prevent duplicates. I therefore had to
    > take steps in my code to detect and suppress them. The NTP client component
    > I had used previously had taken no account of this. RFC2030 only hints at
    > the problem. I am amazed.
    >
    > My questions are therefore:
    > 1) Do ALL good NTP clients take steps to suppress duplicate requests and/or
    > replies, or do they survive by assuming that they don't occur very often? My
    > original survived 18 months without being hit, but my friend in Belgium was
    > hit by 1 repeat in 1000 or so, which rendered the NTP process unusable.
    >
    > 2) Knowing that the UDP protocol can produce spurious repeats, I would have
    > thought the NTP server could detect them and suppress the repeated replies.
    > Do they do this or am I being naive?
    >
    > 3) Does anyone have any figures for the incidence of UDP repeats? What sort
    > of delay would one expect between the original and the repeat? I am seeing
    > figures of 5 minutes or more, which really surprises me. Maybe my friend
    > has a particularly noisy ADSL connection.
    >
    > 4) What's the usual way of suppressing duplicate replies? Comparing a local
    > copy of the request's xmit timestamp with the reply's orig. timestamp seems
    > the obvious.
    >
    > If these questions have come to the wrong place, would some kind soul point
    > it (or me) in a better direction.
    >
    > Thanks.
    >
    > Peter Martinez
    > NorthWest UK.
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


  13. Re: NTP client basic

    In article Harlan Stenn
    writes:
    >
    >As I recall SNTP may send out a bunch of requests but then it believes the
    >first answer it gets. Any other answers should just be dropped.


    The SNTP spec doesn't say anything about sending multiple requests as
    far as I can see. The program called "sntp" in the reference
    implementation distribution might do something like that, it was a while
    since I looked at it, but it sounds like a really stupid thing to do -
    if you send multiple requests, you should of course give all the replies
    at least a chance to arrive, since you will then have a much better
    basis for determining the actual time.

    --Per Hedeland
    per@hedeland.org

  14. Re: NTP client basic

    Hal,

    In the far distant past, the most likely source of retransmissions was
    link-level retransmissions. In any case, the NTP on-wire protocol
    discards duplicates and bogus packets anyway. It does no good whatsoever
    to retransmit unanswered packets. If necessary, transmit a new packet
    with current timestamps.

    Dave

    Hal Murray wrote:

    >>When the repeats still appeared in my own SNTP client implementation (now
    >>trapped, but logged), it seemed to me that I might have stumbled on a
    >>possible source of trouble. RFC2030 didn't seem to say that you MUST take
    >>steps to discard repeats which COULD arise in the underlying UDP protocol,
    >>it seemed to be saying that you could keep an eye on the xmit timestamp in
    >>the request - but it's not essential. RFC768 (which describes UDP) doesn't
    >>shed any light on whether a corrupted UDP packet could be repeated.

    >
    >
    > It's possible but very very unlikely for the network to duplicate
    > a packet.
    >
    > Is your code retransmitting if you don't get an answer? If so, a
    > likely explanation is that you aren't waiting long enough. In
    > any case, your code should filter out duplicates and/or process
    > them correctly.
    >


  15. Re: NTP client basic

    Harlan,

    SNTP doesn't do anything of the kind. It assumes only a single packet
    exchange resulting in four timestamps to determine the time and optional
    offset and roundtrip delay. As described in both RFC 1305 and the NTP4
    draft specification, the timestamps and certain state variables resist
    old duplicates and bogus packets. It is completely nonproductive to send
    a speculative number of packets and believe only the first one. If
    necessary, send a packet and wait a window turn, then send another one
    if lost.

    Dave

    Harlan Stenn wrote:

    > Also,
    >
    > As I recall SNTP may send out a bunch of requests but then it believes the
    > first answer it gets. Any other answers should just be dropped.
    >
    > You should also be able to compare your transmit time to the transmit time
    > in the return answers and throw away ones that don't match.
    >
    > The spec should have a much better list of "how to handle packets".
    >
    > H


  16. Re: NTP client basic

    Dave,

    >>> In article , mills@udel.edu writes:


    mills> Harlan, SNTP doesn't do anything of the kind. It assumes only a
    mills> single packet exchange resulting in four timestamps to determine the
    mills> time and optional offset and roundtrip delay.

    I was talking about the case where SNTP is contacting several hosts.

    In that case it will send a bunch of packets (one to each host).

    Sorry I wasn't more clear.

    H

  17. Re: NTP client basic

    In article mills@udel.edu writes:
    >
    >SNTP doesn't do anything of the kind. It assumes only a single packet
    >exchange resulting in four timestamps to determine the time and optional
    >offset and roundtrip delay. As described in both RFC 1305 and the NTP4
    >draft specification, the timestamps and certain state variables resist
    >old duplicates and bogus packets.


    Yeahbut, RFC 2030 specifically says that you don't need to look at
    1305.:-)

    > It is completely nonproductive to send
    >a speculative number of packets and believe only the first one. If
    >necessary, send a packet and wait a window turn, then send another one
    >if lost.


    Uh, how long is "a window turn"? Just curious...

    --Per Hedeland
    per@hedeland.org

  18. Re: NTP client basic

    Harlan,

    This is even more bogus. True, current ntpdate does send multiple
    packets, not to different servers, but the same server. The program
    attempts to mitigate the multiple replies in some sense to "improve" the
    accuracy. Presumably, some j-random algorithm is used to do this, but
    not the one used in the specification and reference implementation. I'm
    not going to argue with that other than to point out ntpd operated in
    ntpdate mode already has the crafted algorithms and worthy defenses
    against bogus attacks.

    Dave

    Harlan Stenn wrote:
    > Dave,
    >
    >
    >>>>In article , mills@udel.edu writes:

    >
    >
    > mills> Harlan, SNTP doesn't do anything of the kind. It assumes only a
    > mills> single packet exchange resulting in four timestamps to determine the
    > mills> time and optional offset and roundtrip delay.
    >
    > I was talking about the case where SNTP is contacting several hosts.
    >
    > In that case it will send a bunch of packets (one to each host).
    >
    > Sorry I wasn't more clear.
    >
    > H


  19. Re: NTP client basic

    In article "David L. Mills"
    writes:
    >
    >This is even more bogus. True, current ntpdate does send multiple
    >packets, not to different servers, but the same server.


    It sends multiple packets to each of however many servers you care to
    give it on the commandline. Not that I know what this has to do with
    SNTP (whether the protocol or the program).

    --Per Hedeland
    per@hedeland.org

  20. Re: NTP client basic

    And I was talking about sntp, which sends a time request packet to each host
    mentioned on the command line.

    H

+ Reply to Thread
Page 1 of 2 1 2 LastLast