-------- Messaggio originale -------- Da: Alessandro Bolletta <[email protected]> Data: A: [email protected] 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 <[email protected]> Data: A: Alessandro Bolletta <[email protected]> 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 <[email protected]<mailto:[email protected]>> wrote: Why do you think that bridges could be source of bufferbloat? -- Alessandro Bolletta Mediaspot srl Dave Taht <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Data: A: Alessandro Bolletta <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Data: A: Alessandro Bolletta <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> 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" <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://lists.bufferbloat.net/listinfo/codel -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
