Subject: [iccrg] Fwd: measuring delay across wireless links

From: Douglas Leith <[email-masked]>
Date: Fri, 2 Aug 2013 08:41:20 +0100

Apologies, I sent this to the old list address.

Doug

Begin forwarded message:

> From: Douglas Leith <[email-masked]>
> Subject: measuring delay across wireless links
> Date: 31 July 2013 13:37:40 GMT+01:00
> To: "[email-masked] list" <[email-masked]>
> Bcc: Douglas Leith <[email-masked]>
> 
> Here's a link to the article I mentioned:
> 
> http://www.hamilton.ie/net/inferring.pdf
> 
> This is for wifi - the situation might be different for other sorts of wireless link of course.
> 
> Doug

---

From: Mark Handley <[email-masked]>
Date: Fri, 02 Aug 2013 04:16:17 -0700

Thanks Doug, some food for thought in these results.  

Have you tried any measurements with 802.11n, as opposed to 802.11b/g in
your paper?  The reason I ask is that 'n' introduces batching - up to 42
packets can be sent in one batch without needing to re-acquire the
medium.  It needs to do this at higher bitrates to get even vaguely
acceptable throughput, or it would spend all its time on medium
acquisition and almost none on sending packets.

Batching might add less randomness (fewer medium acquisitions), but the
RTT variation imposed by batching itself might affect the results.  In
addition, if you keep few packets in the queue, 802.11n can't batch
effectively.  At high bitrates, not being able to batch would
drastically reduce the link's throughput.  You could easily imagine a
congestion control scheme trying to avoid adding queuing delay, and as a
result getting terrible medium utilization as it falls back to sending
very few packets per batch.

Mark

On Fri, Aug 2, 2013, at 12:41 AM, Douglas Leith wrote:
> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
> Email had 1 attachment:
> + smime.p7s
>   7k (application/pkcs7-signature)

---

From: Douglas Leith <[email-masked]>
Date: Fri, 2 Aug 2013 15:10:01 +0100

Thanks for the comments Mark.  I've seen quite a few measurement tests of coded tcp over 802.11n WLANs in the "wild" e.g. at the IETF meeting itself, and various hotspots, without obvious problems (still interesting throughput gains etc).  That said, I think it would be v. interesting to setup a controlled 802.11n link in the lab to allow us to dig into the impact of batching in a reproducible way - I'll add it to my "to do" list.

Doug

---

From: Dave Taht <[email-masked]>
Date: Fri, 2 Aug 2013 12:43:30 -0700

I can talk to this subject in enormous detail (the current wireless-n
deployment  is something of a botch)... but not today.

I encourage! independent measurements of real systems claiming to do
wireless-n as to how effectively they actually aggregate, on real
traffic. Clients can aggregate fairly well, APs far less so. The
problem starts when manufacturers merely claim full duplex rates for a
half duplex medium, then run unidirectional traffic through it it
testing rather than testing tcp, and further equip aps with fairly
weak processors that can't handle that rate with a reasonable number
of rules...

At least under linux's minstrel-ht rate control algorithm on the
ath9k, some useful statistics, including aggregation, are at:

cat /sys/kernel/debug/ieee80211/phy*/ath9k/xmit (as well as queues)

Of late, I've been fiddling with the rrul test suite, and owamp, to
get one way delay measurements under load. With gps-synced pps ntp
clocks I can get reliable resolutions down to 1ms pretty easily on
10ms packet intervals, the next big problem there is processor
scheduling delay (owamp and owping would benefit from escalated
realtime privs at those levels if you are also running other loads,
and haven't done that patch yet)

rrul and rrul_unclassified is here. It requires an up to date (2.6)
version of netperf on both sides.

https://github.com/tohojo/netperf-wrapper/

owamp:

http://www.internet2.edu/performance/owamp/

I am using the macx-1 usb gps's which support PPS.

Some results from a recent data set: - with 802.11e classification in play:

http://results.lab.taht.net/20s_NoOffloads_BQL9000_IPv6_Atoms_wifi_beagle-28499/20s_NoOffloads_BQL9000_IPv6_Atoms_wifi_beagle-fq_codel-all_scaled-rrul.svg

Without:

http://results.lab.taht.net/20s_NoOffloads_BQL9000_IPv6_Atoms_wifi_beagle-28499/20s_NoOffloads_BQL9000_IPv6_Atoms_wifi_beagle-fq_codel-all_scaled-rrul_noclassification.svg

Way more detail if you look in the directories around there, please
note these tests above were tests using various qdiscs on both ends,
the center ap in this case was using fq_codel. (Present day behavior
with the ap running pfifo_fast are far more miserable...)

These particular tests do not look into aggregation in detail,
either... (they just point out the issues in present day 802.11e, if
anything), there is some slow work taking place on other issues in the
stack, mostly summarized here:

http://www.bufferbloat.net/projects/cerowrt/wiki/Fq_Codel_on_Wireless

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Dave Taht <[email-masked]>
Date: Fri, 2 Aug 2013 13:26:41 -0700

On Fri, Aug 2, 2013 at 12:43 PM, Dave Taht <[email-masked]> wrote:
> anything)

They are also using various forms of udp classified-like ping and ping
to exercise those hw queues, and not owamp (as yet). (ton of owamp related
WIP)

Anyway...

netperf -Y CS1,CS1 [the rest of your test options] tries to set
diffserv CS1 in both directions.

Nearly ALL of the rest of the results living off the url above have
been of tests run while
validating various bits of new hardware, and me dealing with various issues
that showed up. The first above two links offered results consistent
with the theoretical setup, many of the rest in the directories above
do NOT! and I don't have notes up there as to what went wrong in each
test... (very much WIP here...)

you can also exercise different forms of tcp with netperf 2.6 (and
iperf) as well if they are compiled into your kernel. Regrettably I
don't trust the current tcp-ledbat cc module, here's reno vs lp vs
westwood.... The only thing useful you can draw from this one (over
100Mbit ethernet) is that fiddling with different congestion control
algos is "interesting", and I should get around to trying to make this
test repeatable at various bandwidths and over wifi....

http://results.lab.taht.net/owampd/no_cubic_congest_compare.svg

So... I'd prefer LOTS more people run their own tests on their own
hardware in various environments, as testing wireless has inherently
noisy results, and it's very difficult to get a valid experimental
setup in the first place. Running the rrul test suite at every
conference and hotel I've been to has been generally "interesting" in
the chinese sense.

Hopefully these tests and pointers can give you a leap up on doing
that. I'm very open to suggestions as to other testing methods....

in the hope that these beginning explorations prove useful to someone...

-- 
Dave Täht