Bloat » Cerowrt

-------- Original Message --------
Subject: Re: plot
Date: Fri, 21 Oct 2011 16:25:16 +0200
From: Fabian Schneider <fabian@ieee.org>
To: David Täht <dave.taht@gmail.com>
CC: Jim Gettys <jg@freedesktop.org>, Kathleen Nichols
<nichols@pollere.com>

Hi,

Obviously I need to learn enough R to be able to do this sort of analysis myself. In the interim, since I'm doing a similar experiment monday (this time varying either classification of ping or the queue-ing algorithm, not the buffer size - I haven't decided which), we'd love to see your script in the hope I can immediately use it in the class...

Ok. lets see. I created something that should ease up the plotting. See attached tar archive and sample plot. To summarize there is a Makefile which plots the data and expects:
- p1.txt and p2.txt as input (which should be the logs from the ping command)
- awk and sed to be installed and in the path
- GNU R to be installed and in the path

What it does is:
1.) extracts the RTT timeseries 'hopefully' covering the download period, by looking for the ping sequence number (SEQ) with maximum RTT (MAX) and considering all RTTs from SEQ-100 to SEQ+100.
2.) replacing all timeouted pings with an RTT value of MAX+100ms, where the 100ms can be configured in the BEGIN clause of the awk script.
3.) plot the two time series.

What it includes:
- extract.timeseries.awk (performs steps 1+2)
- plotit.R (performs step 3)
- Makefile (wrapper)
- p*.txt example input files

As for these plots, what I'd like:

the Y axis to stay in the the same range of 0 - 1000 ms

(for the combined plot i determine the maximum RTT and use that as an upper bound)

the X axis to be 100 seconds long, showing the idle period, the spike, the idle period.

(i opted for a 200 second = 200 ping samples period instead)

the two plots to be directly comparable, using a different color for the ping 'dots', and roughly the same start time, so I can overlay them...

already done. Only one output plot.

1) start time is uncontrolled (but close enough, given the length of transfer)

you can 'tune' the input data and have the input file start at a chosen point in time that is less than 100 seconds before the maximum to achieve this.
(I did not want to get into more sophisticated methods for determining the download period from the data, sofar)

4) tcpdump on at least several stations would be VERY interesting. Dario says you were seeing some interesting duplicate acks - I still haven't verified we've actually FIXED the stack enough to get reliable results.

No what we saw is ping reporting "(DUP!)" behind some lines.

Would you be interested in following up this line of work with a paper w/me/etc?

sure.

best
Fabian

I just wanted to express how (other than the dup ping issue) utterly
happy I am with the attached txqueuelen37 vs 1000 plot.

txqueuelen 37 REALLY works vs 1000 - and the real sources of the
bottlenecks have moved to the clients, not the AP. On to testing queue
management!

Is 37 the right number? don't know. Is it a better number than 1000 -
you betcha!

Andrew, are you still thinking 100 is better for google's iw10 mice attack?

oh, I forgot to mention what REALLY tweaked me (athough it's not shared by the remainder of the data set and is probably totallllly a matter of mere misfortune) and made me jump at shadows like this one.

first dup is packet 67
second dup is packet 104.

104-67 = 37, which is my txqueuelen.

Seemed fixed. TXquelen == 40 seems to have fixed it..... Bizarre.