Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Dec 2005 15:12:47 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Vlad GALU <vladgalu@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: cwnd and sstresh monitor
Message-ID:  <20051201150949.W56270@fledge.watson.org>
In-Reply-To: <79722fad0512010559n29e957f5j47c99586ebbd3a0f@mail.gmail.com>
References:  <438F00D8.4040302@spintech.ro> <79722fad0512010559n29e957f5j47c99586ebbd3a0f@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 1 Dec 2005, Vlad GALU wrote:

> On 12/1/05, Alin-Adrian Anton <aanton@spintech.ro> wrote:
>> Dear Hackers,
>>
>>         I would like to monitor the changes of cwnd and sstresh values during
>> TCP traffic, in order to plot graphs and interpret congestion.
>>
>>         So I need (cwnd, timestamp) and (sstresh, timestamp) records to be
>> taken everytime one of the two variables is modified.
>>
>>         I'd like to ask you for suggestions, which would be the best aproach
>> (kernel patch, kernel module, etc?), and how would this be done best?
>> (the interception of values, the storage of snapshots, etc)?
>>
>
>   Does exporting them via sysctl, and graph them using anything
> (rrdtool) sound reasonable ?

I've not used it, but there is a TCPDEBUG kernel option that gathers TCP 
state information for debugging and tracing purposes.  I know this has 
been used quite effectively in the past for this sort of work, but 
unfortunately I know very little about it.  With all the TCP changes in 
the last few years (SACK, etc), it could be that it needs some 
enhancements, cleanups, fixes, etc.

In addition, in FreeBSD 6.0, I've added support for a subset of the 
TCP_INFO API, which allows applications to poll various pieces of TCP 
connection state information using a socket option, TCP_INFO. 
Unfortunately, it's polled, not event-driven, so it is possible to miss 
state transitions.

Another thing that I've been thinking about for a while is adding new 
KTR(4) traces for TCP events.  This would be quite straight forward to do, 
but is more of a debugging feature than a live real-world use feature, as 
KTR is more of a debugging trace system.  However, it's very easy to 
instrument new data gathering into KTR -- take a look at the various CTR 
calls in the kernel, and also at the KTR<->ALQ support that lets KTR dump 
trace data to a file.

Robert N M Watson



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051201150949.W56270>