Bug #289

Fwd: Re: plot

Added by David Taht on Oct 21, 2011. Updated on Apr 21, 2012.
Closed Normal Dave Täht

Description

——– 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

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

Attachments

  • plot.ps (image/ps; 24.5 kiB) David Taht Oct 21, 2011

History

Updated by Jim Gettys on Nov 18, 2011.
Being put in wiki
Updated by Dave Täht on Apr 21, 2012.

This is a static export of the original bufferbloat.net issue database. As such, no further commenting is possible; the information is solely here for archival purposes.
RSS feed

Recent News & Articles

Mar 21, 2019 Wiki page
Dave Taht's Take on TCP
Mar 17, 2019 Wiki page
Jake Holland's Stance on ECN
Sep 6, 2018 Wiki page
Pete Heist's Thoughts on ECN
Sep 5, 2018 Wiki page
Dave Taht's Stance on ECN
Sep 4, 2018 Wiki page
Jonathan Morton's Take on ECN

Find us elsewhere

Bufferbloat Mailing Lists
#bufferbloat on Twitter
Google+ group
Archived Bufferbloat pages from the Wayback Machine

Sponsors

Comcast Research Innovation Fund
Nlnet Foundation
Shuttleworth Foundation
GoFundMe

Bufferbloat Related Projects

Congestion Control Blog
Lede Project (OpenWrt)
Flent Network Test Suite
Sqm-Scripts
The Cake shaper
AQMs in BSD
IETF AQM WG

Network Performance Related Resources


Jim Gettys' Blog - The chairman of the Fjord
Toke's Blog - Karlstad University's work on bloat
Voip Users Conference - Weekly Videoconference mostly about voip
Candelatech - A wifi testing company that "gets it".