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>