ntpq, pool

[Hal Murray]

gem at rellim.com said:
>> I assume that's a typo.  The counter has to be in ntpq
>> rather than ntpd. ntpd doesn't store any state for clients.
> My experiments with the lastest ntpmon contradict your statement.
> ntpd does seem to be keeping the number of requests in the mrulist between
> ntpmon runs. 

Please say more.  I can't quite figure out what you are trying to say.

The server does keep track of the number of slots, but that's not per-client 
state.

The server has N MRU slots.  It may grow over time as new clients appear.  
There is a default limit and you can set it in the config file.  When the 
slots fill up, old ones get recycled.

The client asks for a batch of slots, starting with the oldest.  For the 
second and following, it says "please continue from this one" with the 
complications of dancing around slots getting either recycled or bumped to 
the top because traffic for that slot arrived during the processing of the 
previous batch.

The "this one" is state info, but it's stored at the ntpq client rather than 
the server.



-- 
These are my opinions.  I hate spam.