NTPD concurrent clients limit - NTP

This is a discussion on NTPD concurrent clients limit - NTP ; 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 ...

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

Thread: NTPD concurrent clients limit

  1. NTPD concurrent clients limit

    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.

  2. Re: NTPD concurrent clients limit

    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.

    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.

    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

    "Richard B. Gilbert" writes:

    >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

    Unruh wrote:
    > "Richard B. Gilbert" writes:
    >
    >> 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?


    Ntpd keeps a list of its clients. It should be able to tell if a
    particular client is initializing or is abusing the server.

  5. Re: NTPD concurrent clients limit

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




  6. Re: NTPD concurrent clients limit

    "Richard B. Gilbert" writes:

    >Unruh wrote:
    >> "Richard B. Gilbert" writes:
    >>
    >>> 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?


    >Ntpd keeps a list of its clients. It should be able to tell if a
    >particular client is initializing or is abusing the server.


    And how would it tell? And how DOES it tell ( since there is a lot that
    could have been programed in and wasn't). And why would it keep a list of
    its clients. That could mean it would have to keep a lost of 1000000
    clients, and how does it prune the list? And how does it check that the
    latest request is from an abuser, from a newcomer, or from a good guy?




  7. Re: NTPD concurrent clients limit

    Unruh wrote:
    > "Richard B. Gilbert" writes:
    >
    >> Unruh wrote:
    >>> "Richard B. Gilbert" writes:
    >>>
    >>>> 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?

    >
    >> Ntpd keeps a list of its clients. It should be able to tell if a
    >> particular client is initializing or is abusing the server.

    >
    > And how would it tell? And how DOES it tell ( since there is a lot that
    > could have been programed in and wasn't). And why would it keep a list of
    > its clients. That could mean it would have to keep a lost of 1000000
    > clients, and how does it prune the list? And how does it check that the
    > latest request is from an abuser, from a newcomer, or from a good guy?
    >
    >
    >


    Ntpd can and does store the identity of several hundred client and with
    the proper incantation can be made to divulge their identities.

    Do you, by any chance, recall the NTP survey that was done in 2005 by a
    man in Brazil? He had a program that would "crawl the web" and locate
    virtually all the systems that would respond to an ntpdc query (or maybe
    it was ntpq he used). In any case this crawler found several thousand
    machines serving time and got a list of their clients. Each server
    revealed it's connections to other servers and clients.

    See http://www.ntpsurvey.arauc.br/ for the details.

  8. Re: NTPD concurrent clients limit

    Bill,

    See the Rate Management and the Kiss-o'-Dearh page in the current NTP
    documentation on the web.

    Dave

    Unruh wrote:

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


  9. Re: NTPD concurrent clients limit

    Phil,

    See the limit and kod restrict options in the Access Control Options
    page in the current web documentation.

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

    >
    >
    >


  10. Re: NTPD concurrent clients limit

    BBill,

    The ntpd does keep a most-recently--used list and has for almost twenty
    years. It has been used by NIST, USNO and here to find and punish
    abusers. See the papers referenced on the NTP project page. The most
    interesting case was finding the abusers in a flood of 3000 packets per
    second with three load-balanced servers.

    Dave

    Unruh wrote:

    > "Richard B. Gilbert" writes:
    >
    >
    >>Unruh wrote:
    >>
    >>>"Richard B. Gilbert" writes:
    >>>
    >>>
    >>>>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?

    >
    >
    >>Ntpd keeps a list of its clients. It should be able to tell if a
    >>particular client is initializing or is abusing the server.

    >
    >
    > And how would it tell? And how DOES it tell ( since there is a lot that
    > could have been programed in and wasn't). And why would it keep a list of
    > its clients. That could mean it would have to keep a lost of 1000000
    > clients, and how does it prune the list? And how does it check that the
    > latest request is from an abuser, from a newcomer, or from a good guy?
    >
    >
    >


  11. Re: NTPD concurrent clients limit

    Richard,

    There have been several surveys of the public NTP subnet beginning from
    1997. The results then are reported in a briefing and paper available at
    the NTP project site. Surveys of this kind are discouraged in modern
    times as they set off intrusion alerts and nasty complaints. Once upon a
    time it was chic to observe that the Sun never sets on NTP, but suffice
    to say now that NIST estimates 25 million NTP clients of their public
    servers now.

    Dave

    Richard B. Gilbert wrote:

    > Unruh wrote:
    >
    >> "Richard B. Gilbert" writes:
    >>
    >>> Unruh wrote:
    >>>
    >>>> "Richard B. Gilbert" writes:
    >>>>
    >>>>> 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?

    >>
    >>
    >>> Ntpd keeps a list of its clients. It should be able to tell if a
    >>> particular client is initializing or is abusing the server.

    >>
    >>
    >> And how would it tell? And how DOES it tell ( since there is a lot that
    >> could have been programed in and wasn't). And why would it keep a list of
    >> its clients. That could mean it would have to keep a lost of 1000000
    >> clients, and how does it prune the list? And how does it check that the
    >> latest request is from an abuser, from a newcomer, or from a good guy?
    >>
    >>
    >>

    >
    > Ntpd can and does store the identity of several hundred client and with
    > the proper incantation can be made to divulge their identities.
    >
    > Do you, by any chance, recall the NTP survey that was done in 2005 by a
    > man in Brazil? He had a program that would "crawl the web" and locate
    > virtually all the systems that would respond to an ntpdc query (or maybe
    > it was ntpq he used). In any case this crawler found several thousand
    > machines serving time and got a list of their clients. Each server
    > revealed it's connections to other servers and clients.
    >
    > See http://www.ntpsurvey.arauc.br/ for the details.


  12. Re: NTPD concurrent clients limit

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

    >>
    >>
    >>


  13. Re: NTPD concurrent clients limit

    "David L. Mills" writes:

    >BBill,


    >The ntpd does keep a most-recently--used list and has for almost twenty
    >years. It has been used by NIST, USNO and here to find and punish
    >abusers. See the papers referenced on the NTP project page. The most
    >interesting case was finding the abusers in a flood of 3000 packets per
    >second with three load-balanced servers.


    How long is the list?


    >Dave


    >Unruh wrote:


    >> "Richard B. Gilbert" writes:
    >>
    >>
    >>>Unruh wrote:
    >>>
    >>>>"Richard B. Gilbert" writes:
    >>>>
    >>>>
    >>>>>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?

    >>
    >>
    >>>Ntpd keeps a list of its clients. It should be able to tell if a
    >>>particular client is initializing or is abusing the server.

    >>
    >>
    >> And how would it tell? And how DOES it tell ( since there is a lot that
    >> could have been programed in and wasn't). And why would it keep a list of
    >> its clients. That could mean it would have to keep a lost of 1000000
    >> clients, and how does it prune the list? And how does it check that the
    >> latest request is from an abuser, from a newcomer, or from a good guy?
    >>
    >>
    >>


  14. Re: NTPD concurrent clients limit

    On 2008-07-31, Unruh wrote:

    > Since the current web documentation refers to the current version of ntp,


    The documentation at http://www.eecis.udel.edu/~mills/ntp/html/ applies
    to the current NTP Development version.

    Documentation for each release of NTP is included in the ./html/
    directory of that release.

    Documentation for Stable Releases of NTP is available in the searchable
    NTP Documentation Archive at http://doc.ntp.org. The NTP Documentation
    Archive currently houses documentation for: 4.2.4, 4.2.2p4, 4.2.2,
    4.2.0, 4.1.2, 4.1.1, 4.1.0, 3-5.93e.

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


    ntpq -c"rv 0 version" will provide the version number if they are using
    The NTP Reference Implementation.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  15. Re: NTPD concurrent clients limit

    Bill,

    The default behavior has not changed. As the documentation says, the
    rate limit and kod must be explicitly enabled. You don't need to ask the
    operator about the version; an rv command in ntpq reveals it for all to see.

    Dave

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


  16. Re: NTPD concurrent clients limit

    Bill,

    The default MRU list presently contains 600 entries. If more than that
    number of distinct addresses are found, a probabilistic test determines
    whether the oldest entry on the list or the new entry are discaded.
    Experience at NIST shows the lifetime of the oldest entry on thelist is
    typically less than one minute at 3000 pkt/s, but the list still
    contains the rascals we need to punch. Anything else you might need to
    know is on the Rate Management and Kiss-o'-Death page.

    Dave

    Unruh wrote:

    > "David L. Mills" writes:
    >
    >
    >>BBill,

    >
    >
    >>The ntpd does keep a most-recently--used list and has for almost twenty
    >>years. It has been used by NIST, USNO and here to find and punish
    >>abusers. See the papers referenced on the NTP project page. The most
    >>interesting case was finding the abusers in a flood of 3000 packets per
    >>second with three load-balanced servers.

    >
    >
    > How long is the list?
    >
    >
    >
    >>Dave

    >
    >
    >>Unruh wrote:

    >
    >
    >>>"Richard B. Gilbert" writes:
    >>>
    >>>
    >>>
    >>>>Unruh wrote:
    >>>>
    >>>>
    >>>>>"Richard B. Gilbert" writes:
    >>>>>
    >>>>>
    >>>>>
    >>>>>>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?
    >>>
    >>>
    >>>>Ntpd keeps a list of its clients. It should be able to tell if a
    >>>>particular client is initializing or is abusing the server.
    >>>
    >>>
    >>>And how would it tell? And how DOES it tell ( since there is a lot that
    >>>could have been programed in and wasn't). And why would it keep a list of
    >>>its clients. That could mean it would have to keep a lost of 1000000
    >>>clients, and how does it prune the list? And how does it check that the
    >>>latest request is from an abuser, from a newcomer, or from a good guy?
    >>>
    >>>
    >>>


  17. Re: NTPD concurrent clients limit

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




  18. Re: NTPD concurrent clients limit

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

    >
    >


  19. Re: NTPD concurrent clients limit

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

    >>



  20. Re: NTPD concurrent clients limit

    "Phil" writes:

    >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 have no idea how good the Symmetricon designers are. My experience is in
    ppp where loads of people have coded up their own ppp inplimentations ( eg
    phone companies for mobile phone ppp, Microsoft,...) and many of them are
    incompetent. What happens is some summer student comes in and they hand off
    the coding to them, telling them to go look on the net or rfcs to figure
    out how to do it. 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.

    From lurking on this list ( yes, occasionally I just lurk) there have been
    various opinions expressed about things like OpenNTP and other ntp
    implimentations, and occasionally there is someone whose knowledge level of
    ntp is clearly low asking for help in implimenting it. They could have
    been the programmers at Symmetricom.

    You gave no information originally about what the ntp device was that you
    were hooking up to.


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


    Don't denigrate sundials. They are pretty sophisticated devices and until
    about 200 years ago, by far the most accurate timekeepers.

    So, are you able to determine what version of ntp your hardware runs? Or is
    it an SNTP that was coded up by the people who put out the hardware?



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




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