NTPD concurrent clients limit - NTP

This is a discussion on NTPD concurrent clients limit - NTP ; Unruh wrote: "Those poor students come onto the lists asking questions and demonstrating that their knowledge level is low, but they are responsible to putting out the programs that will be used by thousands of people. " Unruh, Stop and ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 41

Thread: NTPD concurrent clients limit

  1. Re: NTPD concurrent clients limit

    Unruh wrote:

    "Those poor students come onto the lists asking questions and
    demonstrating that their knowledge level is low, but they are responsible
    to putting out the programs that will be used by thousands of people. "


    Unruh, Stop and think a moment, as fast as the electronics and software
    industry has gone, if you were a full-time student you still couldn't keep
    up with the "progress" and changes. Consider the boy that started ebay, he
    cobbled up a bunch of canned scripts for lack of programming experience to
    get that thing going. I would say in the end his approach succeeded beyond
    his wildest dreams.

    We all get thrust into positions dealing with the relatively unknown, that's
    how most of us learn and what eventually leads to innovation. That's also
    what got me into electronics in the first place, regardless of how smart you
    are, or what you know, you can never learn it all. The day you stop learning
    is the day you cease to exist.

    Phil



  2. Re: NTPD concurrent clients limit

    Phil,

    You refer to the U Wisconsin incient, but there have been several
    others, including those at NIST and USNO reported in the PTTI paper in
    my list of publications. The rate controls can be used to selectively
    drop abuse packets or to return a KoD in the hope that abusers will
    listen and reduce the rate. Frankly, in the culture of modern times I
    doubt very much the abuser will listen. After some discussion with my
    friends here, a further defense was implemented with result the KoD time
    returned reveals no influence of the server. It's not wrong, it just
    doesn't result in a time adjustment.

    Dave

    Phil wrote:
    > David, Thank you.
    > I'll explore it further when I get some time. After learning of this "kod"
    > packet and since these servers vend time to my applications, I would prefer
    > or need the correct time (no kod) even if something went haywire banging the
    > fool out of a server. To me, no time is better than wrong time. An
    > "excessive use" type of problem should be easily seen from the increased
    > bandwidth.
    >
    > I understand why you implemented "kod" and other safeguards. I have read
    > articles about ntp abuse like that series of cheap routers that had an ip
    > embedded in the firmware that was banging I believe the ucar.edu ntp
    > servers. Seems like you may have been involved in helping isolate that
    > problem. Considering how adaptive the ntpd software has to be, I'm sure it's
    > a delicate balancing act to make it serve the whole of the time community.
    >
    > Phil
    >
    >
    > "David L. Mills" wrote in message
    > news:g6t5g2$o9$1@scrotar.nss.udel.edu...
    >
    >>Phil,
    >>
    >>In the clash of titans one of your questions about whether a canned
    >>version of the rate management stuff exists. There are quite a number of
    >>products using the reference implementation in one form or another, but
    >>not usually a later version. I know that Meinberg even has Autokey in
    >>their product, for example. But, I wouldn't count on any product to
    >>support anything beyond the NTPv4 specification, and that doesn't require
    >>the particulare schemes in the reference version. Another implementation
    >>might do it differently.
    >>
    >>Dave
    >>
    >>Phil wrote:
    >>
    >>>The replies around here sure separate the professionals like David Mills
    >>>and Steve Kostecke from the seemingly arrogant ones like Unruh.
    >>>
    >>>Considering my use of timing is rather critical to my applications I
    >>>don't even depend on the "pool" servers for time. I use my own
    >>>Symmetricom gps disciplined ntp servers, my own Datum/Symmetricom gps
    >>>disciplined rubidium standards for 1PPP and 10 MHz all using
    >>>HP/Symmetricom gps antennas and gps splitters. Sorry, I only have some
    >>>ten GPS based time receivers.
    >>>
    >>>Unruh said "If it is in hardware only it may be some hack
    >>>written by someone whose knowledge of ntp was gained in kindergarten
    >>>class."
    >>>I guess that depends on what you think of the Symmetricom designers,
    >>>engineers, and programmers. I also run the latest release of ntpd
    >>>software on several HP/Compaq Servers.
    >>>
    >>>I'm certain I'm a small fish time user, but I feel with this investment I
    >>>have graduated a little past the sundial and perhaps even a little above
    >>>the average time user.
    >>>
    >>>Phil Harwood
    >>>
    >>>
    >>>"Unruh" wrote in message
    >>>newsUlkk.2876$%b7.390@edtnps82...
    >>>
    >>>
    >>>>"David L. Mills" writes:
    >>>>
    >>>>
    >>>>
    >>>>>Phil,
    >>>>
    >>>>>See the limit and kod restrict options in the Access Control Options
    >>>>>page in the current web documentation.
    >>>>
    >>>>Since the current web documentation refers to the current version of ntp,
    >>>>and since the OP has never told us what version of ntpd he is running or
    >>>>even if it is ntpd he is running, that may not be helpful.
    >>>>
    >>>>In fact he may not know. If it is in hardware only it may be some hack
    >>>>written by someone whose knowledge of ntp was gained in kindergarten
    >>>>class.
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>>Dave
    >>>>
    >>>>>Phil wrote:
    >>>>
    >>>>>>Can the kiss-o'-death packet be disabled ?
    >>>>>>Is this packet also implemented in a "canned" or hardware only ntp
    >>>>>>server?
    >>>>>>Thanks
    >>>>>>Phil Harwood
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>>j. wrote:
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>>Hi all,
    >>>>>>>>>I'm testing an embedded linux device, which implement an NTP server,
    >>>>>>>>>based on the ntpd demon.
    >>>>>>>>>It looks like ntpd accepts only a limited number of requests from a
    >>>>>>>>>test clientIi've set up.
    >>>>>>>>>Do you know if there's such limit or what's the logic behind it?
    >>>>>>>>>Maybe ntpd rejects bursts of requests coming from the same IP?
    >>>>>>>>>
    >>>>>>>>>Thanks in advance,
    >>>>>>>>>Gianandrea Gobbo.
    >>>>>>>
    >>>>>>>>If you poll the server continuously at intervals of less than 64
    >>>>>>>>seconds, most modern NTP servers will send you a "Kiss of Death"
    >>>>>>>>packet.
    >>>>>>>>Polling this frequently is considered abusive! It's also
    >>>>>>>>unnecessary,
    >>>>>>>>NTP is designed to work with poll intervals between 64 seconds and
    >>>>>>>>1024
    >>>>>>>>seconds and will adjust its poll interval within that range as
    >>>>>>>>needed.
    >>>>>>>
    >>>>>>>His question can be rephrased, what does ntpd do after it has sent the
    >>>>>>>Kiss of Death?
    >>>>>>>does it drop all subsequent packets? -- That sounds like a huge cost
    >>>>>>>on
    >>>>>>>the
    >>>>>>>ntp server-- ie imagine a popular server with 10,000 machines it has
    >>>>>>>sent
    >>>>>>>the KoD to. It then has to scan that whole list for each packet to see
    >>>>>>>if
    >>>>>>>it is in there-- something which takes time and destroys the ability
    >>>>>>>of
    >>>>>>>ntp
    >>>>>>>to deliver its time base rapidly.
    >>>>>>>
    >>>>>>>Note that how ntpd handles this situation depends on which version of
    >>>>>>>ntpd
    >>>>>>>you are running.
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>>There are two exceptions to the above. You may specify the "iburst"
    >>>>>>>>keyword for a server and NTPD will send an INITIAL burst of eight
    >>>>>>>>request packets at intervals of two seconds. This is designed for
    >>>>>>>>fast
    >>>>>>>>startup. After the initial burst, polling continues at intervals
    >>>>>>>>between 64 and 1024 seconds.
    >>>>>>>
    >>>>>>>So how does the server know whether this burst is an iburst or is a
    >>>>>>>rogue
    >>>>>>>client to which it should send a KoD?
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>>If you are using a dialup telephone connection for short periods
    >>>>>>>>three
    >>>>>>>>or four times a day, you may specify the "burst" keyword which sends
    >>>>>>>>eight requests two seconds apart at EACH poll interval. "Burst" is
    >>>>>>>>to
    >>>>>>>>be used ONLY for brief periods with LONG intervals between them!
    >>>>>>>
    >>>>>>>>It is customary to request permission from the owner of the server
    >>>>>>>>before using "burst".
    >>>>>>
    >>>>>>
    >>>>>>

    >


  3. Re: NTPD concurrent clients limit

    David,
    For some reason I was under the false impression that kod packet would be
    equivalent to inserting several leap seconds. If that were the case, I could
    potentially be in trouble should I accidentally activate it. I'm guilty of
    taking ntpd for granted since it simply works and haven't studied the
    mechanics or security of it in detail. That is soon to change.

    I may have an application that could conceivably hit timeservers by the tens
    of thousands, and potentially far far greater. It would be from different
    ip's but my concern, should that be the case, it may or could be considered
    a rouge script or equipment causing an attack. I certainly don't want you
    and the rest of the Calvary to be hunting me down. If we follow through on
    this project, we intend to use our own timeservers not only to keep the
    Calvary at bay; I can have better and more accurate control using gps
    disciplined rubidium timebases for the servers.

    Regard that U Wisconsin incident; I was first made aware of it from the U
    Wisconsin side. The article I referenced was put together by one of the
    Wisconsin group detailing the whole experience from discovery through
    resolution. I'll take a look at your papers, should be a good read too.

    Thanks for the time, (take that either way !)
    Phil



    "David L. Mills" wrote in message
    news:g6u0nu$83r$1@scrotar.nss.udel.edu...
    > Phil,
    >
    > You refer to the U Wisconsin incient, but there have been several others,
    > including those at NIST and USNO reported in the PTTI paper in my list of
    > publications. The rate controls can be used to selectively drop abuse
    > packets or to return a KoD in the hope that abusers will listen and reduce
    > the rate. Frankly, in the culture of modern times I doubt very much the
    > abuser will listen. After some discussion with my friends here, a further
    > defense was implemented with result the KoD time returned reveals no
    > influence of the server. It's not wrong, it just doesn't result in a time
    > adjustment.
    >
    > Dave
    >
    > Phil wrote:
    >> David, Thank you.
    >> I'll explore it further when I get some time. After learning of this
    >> "kod" packet and since these servers vend time to my applications, I
    >> would prefer or need the correct time (no kod) even if something went
    >> haywire banging the fool out of a server. To me, no time is better than
    >> wrong time. An "excessive use" type of problem should be easily seen from
    >> the increased bandwidth.
    >>
    >> I understand why you implemented "kod" and other safeguards. I have read
    >> articles about ntp abuse like that series of cheap routers that had an ip
    >> embedded in the firmware that was banging I believe the ucar.edu ntp
    >> servers. Seems like you may have been involved in helping isolate that
    >> problem. Considering how adaptive the ntpd software has to be, I'm sure
    >> it's a delicate balancing act to make it serve the whole of the time
    >> community.
    >>
    >> Phil
    >>
    >>
    >> "David L. Mills" wrote in message
    >> news:g6t5g2$o9$1@scrotar.nss.udel.edu...
    >>
    >>>Phil,
    >>>
    >>>In the clash of titans one of your questions about whether a canned
    >>>version of the rate management stuff exists. There are quite a number of
    >>>products using the reference implementation in one form or another, but
    >>>not usually a later version. I know that Meinberg even has Autokey in
    >>>their product, for example. But, I wouldn't count on any product to
    >>>support anything beyond the NTPv4 specification, and that doesn't require
    >>>the particulare schemes in the reference version. Another implementation
    >>>might do it differently.
    >>>
    >>>Dave
    >>>
    >>>Phil wrote:
    >>>
    >>>>The replies around here sure separate the professionals like David Mills
    >>>>and Steve Kostecke from the seemingly arrogant ones like Unruh.
    >>>>
    >>>>Considering my use of timing is rather critical to my applications I
    >>>>don't even depend on the "pool" servers for time. I use my own
    >>>>Symmetricom gps disciplined ntp servers, my own Datum/Symmetricom gps
    >>>>disciplined rubidium standards for 1PPP and 10 MHz all using
    >>>>HP/Symmetricom gps antennas and gps splitters. Sorry, I only have some
    >>>>ten GPS based time receivers.
    >>>>
    >>>>Unruh said "If it is in hardware only it may be some hack
    >>>>written by someone whose knowledge of ntp was gained in kindergarten
    >>>>class."
    >>>>I guess that depends on what you think of the Symmetricom designers,
    >>>>engineers, and programmers. I also run the latest release of ntpd
    >>>>software on several HP/Compaq Servers.
    >>>>
    >>>>I'm certain I'm a small fish time user, but I feel with this investment
    >>>>I have graduated a little past the sundial and perhaps even a little
    >>>>above the average time user.
    >>>>
    >>>>Phil Harwood
    >>>>
    >>>>
    >>>>"Unruh" wrote in message
    >>>>newsUlkk.2876$%b7.390@edtnps82...
    >>>>
    >>>>
    >>>>>"David L. Mills" writes:
    >>>>>
    >>>>>
    >>>>>
    >>>>>>Phil,
    >>>>>
    >>>>>>See the limit and kod restrict options in the Access Control Options
    >>>>>>page in the current web documentation.
    >>>>>
    >>>>>Since the current web documentation refers to the current version of
    >>>>>ntp,
    >>>>>and since the OP has never told us what version of ntpd he is running
    >>>>>or
    >>>>>even if it is ntpd he is running, that may not be helpful.
    >>>>>
    >>>>>In fact he may not know. If it is in hardware only it may be some hack
    >>>>>written by someone whose knowledge of ntp was gained in kindergarten
    >>>>>class.
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>>Dave
    >>>>>
    >>>>>>Phil wrote:
    >>>>>
    >>>>>>>Can the kiss-o'-death packet be disabled ?
    >>>>>>>Is this packet also implemented in a "canned" or hardware only ntp
    >>>>>>>server?
    >>>>>>>Thanks
    >>>>>>>Phil Harwood
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>>>j. wrote:
    >>>>>>>>>
    >>>>>>>>>
    >>>>>>>>>
    >>>>>>>>>>Hi all,
    >>>>>>>>>>I'm testing an embedded linux device, which implement an NTP
    >>>>>>>>>>server,
    >>>>>>>>>>based on the ntpd demon.
    >>>>>>>>>>It looks like ntpd accepts only a limited number of requests from
    >>>>>>>>>>a
    >>>>>>>>>>test clientIi've set up.
    >>>>>>>>>>Do you know if there's such limit or what's the logic behind it?
    >>>>>>>>>>Maybe ntpd rejects bursts of requests coming from the same IP?
    >>>>>>>>>>
    >>>>>>>>>>Thanks in advance,
    >>>>>>>>>>Gianandrea Gobbo.
    >>>>>>>>
    >>>>>>>>>If you poll the server continuously at intervals of less than 64
    >>>>>>>>>seconds, most modern NTP servers will send you a "Kiss of Death"
    >>>>>>>>>packet.
    >>>>>>>>>Polling this frequently is considered abusive! It's also
    >>>>>>>>>unnecessary,
    >>>>>>>>>NTP is designed to work with poll intervals between 64 seconds and
    >>>>>>>>>1024
    >>>>>>>>>seconds and will adjust its poll interval within that range as
    >>>>>>>>>needed.
    >>>>>>>>
    >>>>>>>>His question can be rephrased, what does ntpd do after it has sent
    >>>>>>>>the
    >>>>>>>>Kiss of Death?
    >>>>>>>>does it drop all subsequent packets? -- That sounds like a huge cost
    >>>>>>>>on
    >>>>>>>>the
    >>>>>>>>ntp server-- ie imagine a popular server with 10,000 machines it has
    >>>>>>>>sent
    >>>>>>>>the KoD to. It then has to scan that whole list for each packet to
    >>>>>>>>see if
    >>>>>>>>it is in there-- something which takes time and destroys the ability
    >>>>>>>>of
    >>>>>>>>ntp
    >>>>>>>>to deliver its time base rapidly.
    >>>>>>>>
    >>>>>>>>Note that how ntpd handles this situation depends on which version
    >>>>>>>>of ntpd
    >>>>>>>>you are running.
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>>There are two exceptions to the above. You may specify the
    >>>>>>>>>"iburst"
    >>>>>>>>>keyword for a server and NTPD will send an INITIAL burst of eight
    >>>>>>>>>request packets at intervals of two seconds. This is designed for
    >>>>>>>>>fast
    >>>>>>>>>startup. After the initial burst, polling continues at intervals
    >>>>>>>>>between 64 and 1024 seconds.
    >>>>>>>>
    >>>>>>>>So how does the server know whether this burst is an iburst or is a
    >>>>>>>>rogue
    >>>>>>>>client to which it should send a KoD?
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>>If you are using a dialup telephone connection for short periods
    >>>>>>>>>three
    >>>>>>>>>or four times a day, you may specify the "burst" keyword which
    >>>>>>>>>sends
    >>>>>>>>>eight requests two seconds apart at EACH poll interval. "Burst" is
    >>>>>>>>>to
    >>>>>>>>>be used ONLY for brief periods with LONG intervals between them!
    >>>>>>>>
    >>>>>>>>>It is customary to request permission from the owner of the server
    >>>>>>>>>before using "burst".
    >>>>>>>
    >>>>>>>
    >>>>>>>

    >>




  4. Re: NTPD concurrent clients limit

    Phil wrote:
    > Unruh wrote:
    >
    > "Those poor students come onto the lists asking questions and
    > demonstrating that their knowledge level is low, but they are responsible
    > to putting out the programs that will be used by thousands of people. "
    >

    >
    > Unruh, Stop and think a moment, as fast as the electronics and software
    > industry has gone, if you were a full-time student you still couldn't keep


    The type of question that I believe he is thinking of often looks like a
    college homework question and indicates a basic lack of understanding of
    computer technology and how to find and understand fundamental source
    documents (there may be some excuse for the latter in that Microsoft
    documentation tends to lead you in circles around the details, never
    reaching them and the ntpd RFCs are written for mathematicians, not
    software developers).

    Companies should not be using such people without strong supervision.

    Although I don't know whether it comes from using students, or simply
    using people good at time and budgets, but lacking technical knowledge,
    but a lot of commercial internet and web related implementations are
    clearly done by people who didn't understand the basic philosophy behind
    the protocols. For example Microsoft stick quotes round the human
    friendly part of email addresses, because they are sometimes needed to
    protect special characters. However the whole point of the design of
    email addresses and email headers in general, is that they should look
    reasonable when viewed as a memo header. As a consequence, the human
    readable part is carefully specified such that, in normal usage, quotes
    should not be used. There are also many travesties of web standards
    around, which look like they were the result of untrained staff.

    Microsoft made some significant, but conceptually simple, errors in
    implementing SNTP in W32Time, one of which is now grand fathered in.
    (Specifically, I'm thinking of hard coding the stratum at 2, and using
    symmetric active instead of client request modes.)


    Unruh's basic point, though, was that, if you buy an NTP implementation
    and there is any possibility that it wasn't implemented from the
    reference implementation code, it is very likely that it will contain
    significant mis-implementations of the protocol and will almost
    certainly considerably lag behind the current release information (which
    lags behind the development branch that Dr Mills oversees).

    In terms of failing to understand protocols. You are using the
    (original) usenet interface to this forum, but it is actually gatewayed
    to a mailing list. As a result, quite a few lookups are going to get
    done on the xxx top level domain. Ignoring the forgery implications,
    this concentrates excess traffic on a limited number of servers. I use
    ..invalid, which is specially allocated for the purpose of bogus domain
    names, and, even if they don't actually do so, the root servers could
    take steps to cause responses to be cached for a very long time. In any
    case, there are proposals to allocate .xxx.

    > up with the "progress" and changes. Consider the boy that started ebay, he
    > cobbled up a bunch of canned scripts for lack of programming experience to
    > get that thing going. I would say in the end his approach succeeded beyond
    > his wildest dreams.
    >
    > We all get thrust into positions dealing with the relatively unknown, that's


    But here we are only talking about things relatively unknown to us
    personally, in which case the correct solution is to research them, but
    what often happens is people try to get others to give them potted
    answers to that research (usually without providing enough facts to
    confirm that what is being asked is even a resonable approach to the
    underlying problem).

    > how most of us learn and what eventually leads to innovation. That's also


    The people we are talking about don't want to learn; they simply want an
    answer to the current sub-problem.

    > what got me into electronics in the first place, regardless of how smart you
    > are, or what you know, you can never learn it all. The day you stop learning
    > is the day you cease to exist.


  5. Re: NTPD concurrent clients limit

    "Phil" writes:

    >Unruh wrote:
    >
    >"Those poor students come onto the lists asking questions and
    >demonstrating that their knowledge level is low, but they are responsible
    >to putting out the programs that will be used by thousands of people. "
    >


    >Unruh, Stop and think a moment, as fast as the electronics and software
    >industry has gone, if you were a full-time student you still couldn't keep
    >up with the "progress" and changes. Consider the boy that started ebay, he
    >cobbled up a bunch of canned scripts for lack of programming experience to
    >get that thing going. I would say in the end his approach succeeded beyond
    >his wildest dreams.


    >We all get thrust into positions dealing with the relatively unknown, that's
    >how most of us learn and what eventually leads to innovation. That's also
    >what got me into electronics in the first place, regardless of how smart you
    >are, or what you know, you can never learn it all. The day you stop learning
    >is the day you cease to exist.


    I have nothing against the students. They are dumped into an almost
    impossible situation. The question is what is the quality of the software
    that the companies put out? That is what is important.


    >Phil




  6. Re: NTPD concurrent clients limit

    Phil wrote:
    > The replies around here sure separate the professionals like David Mills and
    > Steve Kostecke from the seemingly arrogant ones like Unruh.


    They are all professionals. They have different contributions.

    Dave Mills knows a great deal about the development branch code, as he
    wrote much of it, but is less aware of the state of the released code,
    and even less so of third party implementations and competitors. He
    believe implicitly in the appropriateness of the mathematical parts,
    which he designed.

    Steve has more knowledge about released versions and probably
    competitors, but probably just takes the mathematical parts on trust.

    Unruh is still learning the details of the code, but has raised what I
    consider to be valid challenges to some of the design decisions,
    particularly with regard to whether the mathematical basis is valid for
    NTP as used by the average IT manager or embedded product developer.

    If you think Unruh is arrogant, you should try challenging the
    justification for the mathematical approaches used.

  7. Re: NTPD concurrent clients limit

    David,

    To put a fine point on it, the release procedures here have been
    carefully designed to protect the integrity of the product, both
    development and release. That's why I have insisted that these products
    are released from U Delaware archives and not via third parties. If you
    get it from here, the developers and release crew stand by it.
    Notwithstanding this, there are many, many instances where third parties
    have scooped up the product and modified/damaged it for their own pupose.

    The release version does in fact lag sometimes far beyond the
    development version, especailly over the past year that I have spent
    full time cleaning weeds, updating documentation and refining some
    algorithms, but the same development version will eventually become a
    release version. There is no attempt to evolve the release version in
    different ways other than to apply an emergency patch or two.

    Dave

    David Woolley wrote:
    > Phil wrote:
    >
    >> The replies around here sure separate the professionals like David
    >> Mills and Steve Kostecke from the seemingly arrogant ones like Unruh.

    >
    >
    > They are all professionals. They have different contributions.
    >
    > Dave Mills knows a great deal about the development branch code, as he
    > wrote much of it, but is less aware of the state of the released code,
    > and even less so of third party implementations and competitors. He
    > believe implicitly in the appropriateness of the mathematical parts,
    > which he designed.
    >
    > Steve has more knowledge about released versions and probably
    > competitors, but probably just takes the mathematical parts on trust.
    >
    > Unruh is still learning the details of the code, but has raised what I
    > consider to be valid challenges to some of the design decisions,
    > particularly with regard to whether the mathematical basis is valid for
    > NTP as used by the average IT manager or embedded product developer.
    >
    > If you think Unruh is arrogant, you should try challenging the
    > justification for the mathematical approaches used.


  8. Re: NTPD concurrent clients limit

    Phil wrote:
    > Can the kiss-o'-death packet be disabled ?
    > Is this packet also implemented in a "canned" or hardware only ntp server?
    > Thanks
    > Phil Harwood


    No. Why would you want to? This is to protect the server, not the
    clients. In any case there is more than one type of KOD.

    Danny

  9. Re: NTPD concurrent clients limit

    Danny,
    what will happen I have 100,000 of the same script (different ip's) hitting
    the servers at the same or about same time. That's why I bought my own ntp
    servers. From what I thought I understood by hearing you guys banter about,
    the kod will come into play, or will it.
    Thanks,
    Phil


    "Danny Mayer" wrote in message
    news:489F280A.1000107@ntp.isc.org...
    > Phil wrote:
    >> Can the kiss-o'-death packet be disabled ?
    >> Is this packet also implemented in a "canned" or hardware only ntp
    >> server?
    >> Thanks
    >> Phil Harwood

    >
    > No. Why would you want to? This is to protect the server, not the
    > clients. In any case there is more than one type of KOD.
    >
    > Danny




  10. Re: NTPD concurrent clients limit

    "Phil" writes:

    >Danny,

    o
    100,000? What are you doing?

    >what will happen I have 100,000 of the same script (different ip's) hitting
    >the servers at the same or about same time. That's why I bought my own ntp
    >servers. From what I thought I understood by hearing you guys banter about,


    I'm glad you bought your own servers.

    >the kod will come into play, or will it.


    kod is on individual clients. Ie if a single client starts hitting too
    often in a time period a KOD is sent out. It does not care if 1000000
    others are hitting. Mind you if 100000 are hitting at about the same time,
    the internal tables cannot keept track of that many clients, and I doubt a
    KOD would ever be sent out.

    I do hope you are not hitting with each client once per second or
    something.


    >Thanks,
    >Phil



    >"Danny Mayer" wrote in message
    >news:489F280A.1000107@ntp.isc.org...
    >> Phil wrote:
    >>> Can the kiss-o'-death packet be disabled ?
    >>> Is this packet also implemented in a "canned" or hardware only ntp
    >>> server?
    >>> Thanks
    >>> Phil Harwood

    >>
    >> No. Why would you want to? This is to protect the server, not the
    >> clients. In any case there is more than one type of KOD.
    >>
    >> Danny




  11. Re: NTPD concurrent clients limit

    Unruh, you ask:

    "100,000? What are you doing?"
    For now, just say time. At present, numbers not even good guesstimates.

    "I'm glad you bought your own servers."
    I thought I might piss a bunch off if I didn't, but I need it accurate, gps
    based and dependable.

    "kod is on individual clients"
    Then I doubt anything to worry about, access per incident is restricted.

    "I do hope you are not hitting with each client once per second or
    something."
    We estimate most bandwidth will be single hits and from different ip's. If
    it should be repetitive, perhaps at "minute/s" interval and then limited as
    to total requests and duration before script times out. All the numbers
    still flexible, but everything will be optimized for least server loads and
    minimum bandwidth.

    Phil


    "Unruh" wrote in message
    news:FmEok.7312$nu6.2570@edtnps83...
    > "Phil" writes:
    >
    >>Danny,

    > o
    > 100,000? What are you doing?
    >
    >>what will happen I have 100,000 of the same script (different ip's)
    >>hitting
    >>the servers at the same or about same time. That's why I bought my own ntp
    >>servers. From what I thought I understood by hearing you guys banter
    >>about,

    >
    > I'm glad you bought your own servers.
    >
    >>the kod will come into play, or will it.

    >
    > kod is on individual clients. Ie if a single client starts hitting too
    > often in a time period a KOD is sent out. It does not care if 1000000
    > others are hitting. Mind you if 100000 are hitting at about the same time,
    > the internal tables cannot keept track of that many clients, and I doubt a
    > KOD would ever be sent out.
    >
    > I do hope you are not hitting with each client once per second or
    > something.
    >
    >
    >>Thanks,
    >>Phil

    >
    >
    >>"Danny Mayer" wrote in message
    >>news:489F280A.1000107@ntp.isc.org...
    >>> Phil wrote:
    >>>> Can the kiss-o'-death packet be disabled ?
    >>>> Is this packet also implemented in a "canned" or hardware only ntp
    >>>> server?
    >>>> Thanks
    >>>> Phil Harwood
    >>>
    >>> No. Why would you want to? This is to protect the server, not the
    >>> clients. In any case there is more than one type of KOD.
    >>>
    >>> Danny

    >
    >




  12. Re: NTPD concurrent clients limit


    >His question can be rephrased, what does ntpd do after it has sent the Kiss of Death?
    >does it drop all subsequent packets? -- That sounds like a huge cost on the
    >ntp server-- ie imagine a popular server with 10,000 machines it has sent
    >the KoD to. It then has to scan that whole list for each packet to see if
    >it is in there-- something which takes time and destroys the ability of ntp
    >to deliver its time base rapidly.


    A hash table would solve that problem. (assuming you wanted to
    keep track of many many clients)

    Note also that scanning a long list won't destroy the accuracy.
    NTP uses 2 time stamps, one when the packet arrives and one
    when the packet exits. In between you can do all sorts of things,
    for example crunch away for a while doing crypto stuff.

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


  13. Re: NTPD concurrent clients limit

    "Phil" writes:

    >Unruh, you ask:


    >"100,000? What are you doing?"
    >For now, just say time. At present, numbers not even good guesstimates.


    >"I'm glad you bought your own servers."
    >I thought I might piss a bunch off if I didn't, but I need it accurate, gps
    >based and dependable.


    Yes, buy one or two or three gps receivers with pps and install them on say
    three of your servers, just so you have fallover in case one of them bursts
    into flame. Just buy a GArmin GPS18lvc which is cheap enough, and then wire
    up a decent interface board.

    Use those three as teh servers for your tribe of things.
    They will be good to a few microseconds. YOur local lan will degrade that
    to a few 10s of microseconds, but much better than one millisecond.




    >"kod is on individual clients"
    >Then I doubt anything to worry about, access per incident is restricted.


    >"I do hope you are not hitting with each client once per second or
    >something."
    >We estimate most bandwidth will be single hits and from different ip's. If
    >it should be repetitive, perhaps at "minute/s" interval and then limited as
    >to total requests and duration before script times out. All the numbers
    >still flexible, but everything will be optimized for least server loads and
    >minimum bandwidth.


    Sounds like you have nothing to worry about.



    >Phil



    >"Unruh" wrote in message
    >news:FmEok.7312$nu6.2570@edtnps83...
    >> "Phil" writes:
    >>
    >>>Danny,

    >> o
    >> 100,000? What are you doing?
    >>
    >>>what will happen I have 100,000 of the same script (different ip's)
    >>>hitting
    >>>the servers at the same or about same time. That's why I bought my own ntp
    >>>servers. From what I thought I understood by hearing you guys banter
    >>>about,

    >>
    >> I'm glad you bought your own servers.
    >>
    >>>the kod will come into play, or will it.

    >>
    >> kod is on individual clients. Ie if a single client starts hitting too
    >> often in a time period a KOD is sent out. It does not care if 1000000
    >> others are hitting. Mind you if 100000 are hitting at about the same time,
    >> the internal tables cannot keept track of that many clients, and I doubt a
    >> KOD would ever be sent out.
    >>
    >> I do hope you are not hitting with each client once per second or
    >> something.
    >>
    >>
    >>>Thanks,
    >>>Phil

    >>
    >>
    >>>"Danny Mayer" wrote in message
    >>>news:489F280A.1000107@ntp.isc.org...
    >>>> Phil wrote:
    >>>>> Can the kiss-o'-death packet be disabled ?
    >>>>> Is this packet also implemented in a "canned" or hardware only ntp
    >>>>> server?
    >>>>> Thanks
    >>>>> Phil Harwood
    >>>>
    >>>> No. Why would you want to? This is to protect the server, not the
    >>>> clients. In any case there is more than one type of KOD.
    >>>>
    >>>> Danny

    >>
    >>




  14. Re: NTPD concurrent clients limit

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


    >>His question can be rephrased, what does ntpd do after it has sent the Kiss of Death?
    >>does it drop all subsequent packets? -- That sounds like a huge cost on the
    >>ntp server-- ie imagine a popular server with 10,000 machines it has sent
    >>the KoD to. It then has to scan that whole list for each packet to see if
    >>it is in there-- something which takes time and destroys the ability of ntp
    >>to deliver its time base rapidly.


    >A hash table would solve that problem. (assuming you wanted to
    >keep track of many many clients)


    I think the question is what ntpd does, not what it could do.


    >Note also that scanning a long list won't destroy the accuracy.
    >NTP uses 2 time stamps, one when the packet arrives and one
    >when the packet exits. In between you can do all sorts of things,
    >for example crunch away for a while doing crypto stuff.




  15. Re: NTPD concurrent clients limit

    Guys,

    Please, please and more please, read the Rate Management and the
    Kiss-o'-Death page (rate.html) in the online documentation before
    continuiong this thread.

    Dave

    Unruh wrote:
    > hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
    >
    >
    >
    >>>His question can be rephrased, what does ntpd do after it has sent the Kiss of Death?
    >>>does it drop all subsequent packets? -- That sounds like a huge cost on the
    >>>ntp server-- ie imagine a popular server with 10,000 machines it has sent
    >>>the KoD to. It then has to scan that whole list for each packet to see if
    >>>it is in there-- something which takes time and destroys the ability of ntp
    >>>to deliver its time base rapidly.

    >
    >
    >>A hash table would solve that problem. (assuming you wanted to
    >>keep track of many many clients)

    >
    >
    > I think the question is what ntpd does, not what it could do.
    >
    >
    >
    >>Note also that scanning a long list won't destroy the accuracy.
    >>NTP uses 2 time stamps, one when the packet arrives and one
    >>when the packet exits. In between you can do all sorts of things,
    >>for example crunch away for a while doing crypto stuff.

    >
    >
    >


  16. Re: NTPD concurrent clients limit

    Dave,

    As you and I discussed at the time this is not true of any client
    ignoring the indication of a KOD packet. They will in fact drift further
    and further way from the correct time each time it receives a KOD
    packet. Note that KOD packets are not problem for clients following the
    normal rules of engagement and not bombarding the server.

    Danny

    David L. Mills wrote:
    > Phil,
    >
    > You refer to the U Wisconsin incient, but there have been several
    > others, including those at NIST and USNO reported in the PTTI paper in
    > my list of publications. The rate controls can be used to selectively
    > drop abuse packets or to return a KoD in the hope that abusers will
    > listen and reduce the rate. Frankly, in the culture of modern times I
    > doubt very much the abuser will listen. After some discussion with my
    > friends here, a further defense was implemented with result the KoD time
    > returned reveals no influence of the server. It's not wrong, it just
    > doesn't result in a time adjustment.
    >
    > Dave


  17. Re: NTPD concurrent clients limit

    Phil wrote:
    >
    > I may have an application that could conceivably hit timeservers by the tens
    > of thousands, and potentially far far greater. It would be from different
    > ip's but my concern, should that be the case, it may or could be considered
    > a rouge script or equipment causing an attack. I certainly don't want you
    > and the rest of the Calvary to be hunting me down. If we follow through on
    > this project, we intend to use our own timeservers not only to keep the
    > Calvary at bay; I can have better and more accurate control using gps
    > disciplined rubidium timebases for the servers.
    >


    This concerns me. If you have an application that needs NTP server
    sources requiring those kinds of volumes you should be deploying your
    own NTP servers or negotiating deals with other service providers in
    those countries that you will be delivering your services. Neither the
    stratum 1 or stratum 2 or the pool servers are designed to meet the
    needs of high-volume private applications.

    Danny

  18. Re: NTPD concurrent clients limit

    Danny Mayer wrote:
    > Phil wrote:
    >> I may have an application that could conceivably hit timeservers by the tens
    >> of thousands, and potentially far far greater. It would be from different
    >> ip's but my concern, should that be the case, it may or could be considered
    >> a rouge script or equipment causing an attack. I certainly don't want you
    >> and the rest of the Calvary to be hunting me down. If we follow through on
    >> this project, we intend to use our own timeservers not only to keep the
    >> Calvary at bay; I can have better and more accurate control using gps
    >> disciplined rubidium timebases for the servers.
    >>

    >
    > This concerns me. If you have an application that needs NTP server
    > sources requiring those kinds of volumes you should be deploying your
    > own NTP servers or negotiating deals with other service providers in
    > those countries that you will be delivering your services. Neither the
    > stratum 1 or stratum 2 or the pool servers are designed to meet the
    > needs of high-volume private applications.
    >
    > Danny


    If many systems at a single site are running the application, then
    broadcast or multicast would appear to be viable solutions.

  19. Re: NTPD concurrent clients limit

    Richard B. Gilbert wrote:
    > Danny Mayer wrote:
    >> Phil wrote:
    >>> I may have an application that could conceivably hit timeservers by the tens
    >>> of thousands, and potentially far far greater. It would be from different
    >>> ip's but my concern, should that be the case, it may or could be considered
    >>> a rouge script or equipment causing an attack. I certainly don't want you
    >>> and the rest of the Calvary to be hunting me down. If we follow through on
    >>> this project, we intend to use our own timeservers not only to keep the
    >>> Calvary at bay; I can have better and more accurate control using gps
    >>> disciplined rubidium timebases for the servers.
    >>>

    >> This concerns me. If you have an application that needs NTP server
    >> sources requiring those kinds of volumes you should be deploying your
    >> own NTP servers or negotiating deals with other service providers in
    >> those countries that you will be delivering your services. Neither the
    >> stratum 1 or stratum 2 or the pool servers are designed to meet the
    >> needs of high-volume private applications.
    >>
    >> Danny

    >
    > If many systems at a single site are running the application, then
    > broadcast or multicast would appear to be viable solutions.


    If it's site-local then yes you can do that. Phil seemed to indicate
    that this was going to be all over the Internet, but maybe I
    misunderstood what he was saying.

    Danny

  20. Re: NTPD concurrent clients limit


    > This concerns me. If you have an application that needs NTP server
    > sources requiring those kinds of volumes you should be deploying your
    > own NTP servers or negotiating deals with other service providers in
    > those countries that you will be delivering your services. Neither the
    > stratum 1 or stratum 2 or the pool servers are designed to meet the
    > needs of high-volume private applications.
    >
    > Danny


    Danny and Gang, u didn't read the posts.
    We have our own ntp servers, actually east and west and possibly more in
    future
    Everything is under out control. I have seen some rouge pool servers in the
    past, I wanted eliminate that anyway.

    Fact is we have also been experimenting with replacing clocks in larger
    multi cpu servers with an OCXO timebase board that is phase locked to
    external gps disciplined rubidium standards. Servers will not be an issue,
    bandwidth could be. It may wind up being a modified ntp, but since it's not
    for public access as such, who cares

    Hope that is clear enough, your fears eliminated !



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