Re: ntp time 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.
> 

even with several 'cat' one after the other the connection states all remain 
at 7 on every server. i believe you are right about the connection duration. 
i will ask the timekeeper list about that. i think it would help.

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

absolutely :)


> 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