[Codel] testbed for testing fq_codel on wifi doesn't work as expected

Tue Jun 4 05:42:29 EDT 2013

-------- Messaggio originale --------
Da: Alessandro Bolletta <alessandro at mediaspot.net>
Data:
A: codel at lists.bufferbloat.net
Oggetto: I: Re: R: Re: R: Re: [Codel] testbed for testing fq_codel on wifi doesn't work as expected

Yes Dave, you're right.
For the public list: i'm trying to understand why i'm encountering bufferbloat in a quite simple (but geared with bridges and batman-adv's L2 abstraction. Another info: i'm also using trelay in order to use wifi interface of the nano bridges in the tplink devices avoiding ethernet/802.11 header wrong translation) testbed. I already applied debloat script (the lua based one) to my physical interfaces as eth0 and wlan0 but if i try to load the wifi link with an UDP bidirectional flow I experience bufferbloat and I still couldn't figure out why. Tomorrow I will try to simplify the configuration of the testbed but I'll have to solve this problem because it will be the configuration that we're going to use on our mesh network.

--

Alessandro Bolletta
Mediaspot Srl

-------- Messaggio originale --------
Da: Dave Taht <dave.taht at gmail.com>
Data:
A: Alessandro Bolletta <alessandro at mediaspot.net>
Oggetto: Re: R: Re: R: Re: [Codel] testbed for testing fq_codel on wifi doesn't work as expected

Can we do this stuff in public please?

I think it is possible we are miscommunicating somewhere here.

1) What I'd said elsewhere was that the debloat script did not debloat a bridge, when handed an IFACE=lan-br it doesn't do the right thing.

if you have a bridge, the underlying interfaces need to be debloated, so you'd have (for example eth0 and wlan0 bridged together which need the debloat run on each). We clear there?

2) Bridging wifi and wired together is a bad idea in the case of multicast. So that's a source of bloat given that the interface slows down a lot to deliver multicast.

On Sun, Jun 2, 2013 at 6:43 AM, Alessandro Bolletta <alessandro at mediaspot.net<mailto:alessandro at mediaspot.net>> wrote:

Why do you think that bridges could be source of bufferbloat?
--
Alessandro Bolletta
Mediaspot srl

Dave Taht <dave.taht at gmail.com<mailto:dave.taht at gmail.com>> ha scritto:

Find /sys -name qlen_\*

Set vo to 2 vi to 4 be to 12. Bk to 12. For lowest latency set to 4.

4 will clobber throughput. We are well aware of how to fix aggregation to work well with fq codel but didn't get funded so the best compromise at the moment is about 12.

On Jun 1, 2013 9:31 AM, "Dave Taht" <dave.taht at gmail.com<mailto:dave.taht at gmail.com>> wrote:

As I said debloat doesn't work on bridges you have to apply it to the underlying interfaces. In /etc/rc.local if you must. I never figured out a sane way to parse brctl.

On Jun 1, 2013 9:11 AM, "Alessandro Bolletta" <alessandro at mediaspot.net<mailto:alessandro at mediaspot.net>> wrote:
I tried the lua version but it doesn't seem to apply correctly changes. Is there any common problem that I could have to know?

--

Alessandro Bolletta
Mediaspot Srl

-------- Messaggio originale --------
Da: Dave Taht <dave.taht at gmail.com<mailto:dave.taht at gmail.com>>
Data:
A: Alessandro Bolletta <alessandro at mediaspot.net<mailto:alessandro at mediaspot.net>>
Oggetto: Re: R: Re: [Codel] testbed for testing fq_codel on wifi doesn't work as expected

I don't thinknthe shell based version tweaks on qlen_be.

On Jun 1, 2013 8:51 AM, "Alessandro Bolletta" <alessandro at mediaspot.net<mailto:alessandro at mediaspot.net>> wrote:
Hi Dave,
It seems that the lua-based debloat script doesn't apply changes in tc. Is the bash-based version identical to the lua-based or are there some differences that I might know?

Thanks

--

Alessandro Bolletta
Mediaspot Srl

-------- Messaggio originale --------
Da: Dave Taht <dave.taht at gmail.com<mailto:dave.taht at gmail.com>>
Data:
A: Alessandro Bolletta <alessandro at mediaspot.net<mailto:alessandro at mediaspot.net>>
Cc: codel at lists.bufferbloat.net<mailto:codel at lists.bufferbloat.net>
Oggetto: Re: [Codel] testbed for testing fq_codel on wifi doesn't work as expected

The debloat script does not debloat bridges. You have to apply it to the underlying devices.

IFACE=wlan0 QMODEL=fq_codel_ll debloat

There are numerous other potential problems  below. I advise simplifying your setup.

On Jun 1, 2013 4:34 AM, "Alessandro Bolletta" <alessandro at mediaspot.net<mailto:alessandro at mediaspot.net>> wrote:
Hi everybody,
I made a little testbed in my office with 2 Ubiquiti Nanobridge M5 and 2 TPlink 741nd.
Nanobridges are simply connected in AP-STA mode and relaying traffic to the two TPLinks where i’m running batman-adv. So I bridged the bat0 interface create by batman-adv with one of the ethernet ports offered by the ar71xx CPU. So I connected two laptops to the bridge at both ends and I pushed up a bidirectional UDP flow filling the wifi link available bandwidth (I saw that it constantly runs at 33Mbps in download and 37Mbps in upload).
In every device (tplinks and ubnts) i’m running OpenWRT BARRIER BREAKER (Bleeding Edge, r36692), running on kernel 3.8.12
I executed Dave Taht’s debloat script for bash (and also the lua-compatible one) on every device, but if i try to make a ping starting from a laptop to the opposite laptop, these are the times that I get (sorry, it’s written in italian. “Richiesta scaduta” means “expired reply”):

Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=259ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=281ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=285ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=91ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=130ms TTL=128
Richiesta scaduta.
Richiesta scaduta.
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=251ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=188ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=156ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=279ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=314ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=288ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=324ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=297ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=318ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=301ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=115ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=312ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=292ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=266ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=227ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=91ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=266ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=190ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=161ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=132ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=118ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=166ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=247ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=281ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=282ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=288ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=165ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=251ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=307ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=294ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=297ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=275ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=288ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=282ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=273ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=224ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=159ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=103ms TTL=128
Richiesta scaduta.
Richiesta scaduta.
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=186ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=225ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=299ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=112ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=171ms TTL=128
Richiesta scaduta.
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=175ms TTL=128
Richiesta scaduta.
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=147ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=211ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=279ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=279ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=228ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=219ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=167ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=177ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=197ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=265ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=275ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=237ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=237ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=285ms TTL=128
Richiesta scaduta.
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=166ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=262ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=275ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=30ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=84ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=249ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=244ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=201ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=110ms TTL=128
Richiesta scaduta.
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=220ms TTL=128
Risposta da 192.168.2.25<http://192.168.2.25>: byte=32 durata=240ms TTL=128

While if I ping while i’m not doing traffic at all I get 1ms RTT replies without packet loss.
Can you help me to find the cause of this bufferbloat?

Thanks
Alessandro

_______________________________________________
Codel mailing list
Codel at lists.bufferbloat.net<mailto:Codel at lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/codel

--
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20130604/2eb8e75d/attachment-0002.html>