Re: cwnd and sstresh monitor



Robert Watson wrote:

On Thu, 1 Dec 2005, Vlad GALU wrote:

On 12/1/05, Alin-Adrian Anton <aanton@xxxxxxxxxxx> 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 thought about this too, however, this loses precision and provides constant units of time. Knowing the timestamps for each packet may be interesting to underline timeouts on the graphic.




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.


I used it now, and with a small patch it shows exactly what I need (seq, ack, timestamp, cwnd and ssthresh). I just added my knob to trpt.c .


I also modified the iptime() function to provide microsecond resolution instead of miliseconds, because most of the packets have the same timestamp attached. Still, a decent number of packets have the same timestamp. I'm looking at them only on one side of the connection (the transmitter), I wonder if there is any better solution then timestamping them on both sides - and mixing the values.

Thanks guys for the precious information, it helped a lot!

Yours Sincerely,
--
Alin-Adrian Anton
GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785  2F7C 5823 ABA0 1830 87BA)
gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA

"It is dangerous to be right when the government is wrong." - Voltaire
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: silent semantic changes with reiser4
    ... > Several do TCP in user space. ... mis-behaving (and I'm not saying intentionally so: it might be a small bug ... They will ban an OS if it sends out packets ... that you have another protection domain (aka "kernel" or "TCP deamon") ...
    (Linux-Kernel)
  • TCP timestamp & advanced fingerprinting
    ... attached is a paper from one of our students about using the TCP ... analysis of various operating systems should reveal how analyzing timestamps ... the timestamp value of one point each 500 milliseconds. ... value in their SYN packets, but Windows-based operating systems does not. ...
    (Bugtraq)
  • Re: TCP library
    ... |> my program instead of the normal TCP code? ... |> belong to the kernel as far as I know. ... | can also get the reply packets from the interface. ...
    (comp.os.linux.development.system)
  • Advice on a multithreaded netisr patch?
    ... I'm developing an application that needs a high rate of small TCP ... takes place and offload packets to several new kernel threads. ... think are entry points for packets in the non-netisr.direct case. ... and a similar number of transactions/s in the application. ...
    (freebsd-net)
  • [Full-disclosure] CERT VU#637934
    ... * TCP does not adequately validate segments before updating timestamp value ... * RFC-1323 (TCP Extensions for High Performance) ... * 3.4 defines what timestamp options to accept: ... * for packets with arbitrary th_ack values and th_seq values of half the ...
    (Full-Disclosure)