Re: ntp time requests

i got another response:

"A NTP packet is about 80 bytes. On a 10 Mbit connection, that's about
64 microseconds. On a 100 Mbit connection, 6.4 microseconds. There's
some turnaround time in the stack and processing between receipt and
reply but it's getting even shorter :-).

If you want to see who ntpd's been talking to recently, ntpdc -c monlist
will tell you what you want. You can also turn on various degrees of
logging about communications with peers. I would be very dubious about
getting any information of value from /proc/net/udp (not that I know
what it does but I'd be surprised if you could learn much!)"

i tried it and here are 2 lines out of the 1000+ lines in the resulting file

remote address          port local address      count m ver code avgint  
lstint
===============================================================================
rrcs-71-42-209-74.sw.b 62829 64.113.32.3  1154 1 3     90     16       
0
221.7.39.60               45 64.113.32.3                 16    1 3    90   322 
0


the "count" shows how many times that host requested time.


if you wish to continue this for a new feature ill gladly test it. this file 
gives me what i need but unfortunately it is not an 'at a glance' display nor 
does it give me a "total count" of all hosts. not sure how important  that is 
at the moment but it was one of the boss's requests.


On Sunday 16 September 2007, Bill Wilson wrote:
> On Sun, 16 Sep 2007 09:24:24 -0400
> Rio <[email protected]> wrote:
> 
> > >    46: 010310AC:9C4C 030310AC:1770 01 
> > >    |      |      |      |      |   |--> connection state
> > >    |      |      |      |      |------> remote TCP port number
> > >    |      |      |      |-------------> remote IPv4 address
> > >    |      |      |--------------------> local TCP port number
> > >    |      |---------------------------> local IPv4 address
> > >    |----------------------------------> number of entry
> > > 
> > > Uh, look at that diagram in a fixed width font viewer...
> > > 
> > 
> > i checked several of our servers for a comparison. some  the first item 
counts 
> > sequentially with no deviation, however it repeats 123 for several pages.
> > 
> >  others jump. i have a number of 123 entries in that column in all 
servers. it 
> > appears to be the decimal of the local tcp port number 7B.
> 
> So the connections are showing up.  The inet monitor looks for active 
connections
> as indicated by a "1" in the "connection state" field before it will record 
them.
>  The possible connections states are (from kernel source 
include/net/tcp_states.h):
> 
>     TCP_ESTABLISHED = 1,
>     TCP_SYN_SENT,
>     TCP_SYN_RECV,
>     TCP_FIN_WAIT1,
>     TCP_FIN_WAIT2,
>     TCP_TIME_WAIT,
>     TCP_CLOSE,
>     TCP_CLOSE_WAIT,
>     TCP_LAST_ACK,
>     TCP_LISTEN,
>     TCP_CLOSING,
> 
> and maybe most entries you see in the udp file are residual closed
> connections (connection state 7).  I'm still speculating that the 
established
> state could be so brief that the inet monitor never catches it.  I suppose I
> could test for some state less than TCP_CLOSE to increase the chances,
> but there's the risk that the state values in tcp_states.h might vary with
> kernel versions.  At least established at position "1" can be depended on.
> 
> If I add some extra inet monitor debugging to gkrellm, would you care to do
> some more testing?  I can probably get a new test tarball ready for you
> within a day or so.
> 
> Bill
> _______________________________________________
> Gkrellm mailing list
> [email protected]
> http://lists.jutley.org/cgi-bin/mailman/listinfo/gkrellm
> 


_______________________________________________
Gkrellm mailing list
[email protected]
http://lists.jutley.org/cgi-bin/mailman/listinfo/gkrellm