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

here is the response i just got back from one of the time engineers in the 
timekeepers forum:

"If I understand your question, the answer is "0 seconds". NTP is a 
trivial protocol; a UDP packet comes in to the server, the server sends 
a UDP packet back out to the client, and it's done"

maybe it is not the udp file that needs checking but to query the server 
itself about its own statistics. hmm ... i am beginning to think that 
realtime will be impossible and only historical can be reported.

Geoff Kuenning mentioned fmonitor and fchart that has an ntp query script with 
it. maybe this is the answer? it appears though that the internet monitor 
could keep count of the number of port 123 connections in a historical mode. 
hmm.... i still have to download and check these 2 out.



> 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