Re: NTPD concurrent clients limit
- From: Unruh <unruh-spam@xxxxxxxxxxxxxx>
- Date: Thu, 31 Jul 2008 21:40:01 GMT
"Phil" <phil@xxxxxxxxxxxxx> 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 beenvarious 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" <unruh-spam@xxxxxxxxxxxxxx> wrote in message
news:pUlkk.2876$%b7.390@xxxxxxxxxxx
"David L. Mills" <mills@xxxxxxxx> 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".
.
- Follow-Ups:
- Re: NTPD concurrent clients limit
- From: Phil
- Re: NTPD concurrent clients limit
- Next by Date: Re: NTPD concurrent clients limit
- Next by thread: Re: NTPD concurrent clients limit
- Index(es):
Relevant Pages
|
Loading
