[ntp:questions] NTPD concurrent clients limit

Phil phil at xxxxxxxxx.xxx
Thu Jul 31 21:06:47 UTC 2008


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" <mills at udel.edu> wrote in message 
news:g6t5g2$o9$1 at 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" <unruh-spam at physics.ubc.ca> wrote in message 
>> news:pUlkk.2876$%b7.390 at edtnps82...
>>
>>>"David L. Mills" <mills at udel.edu> 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".
>>>>>
>>>>>
>>>>>
>> 




More information about the questions mailing list