From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mediaspot.net (mail.mediaspot.net [109.73.92.181]) by huchra.bufferbloat.net (Postfix) with ESMTP id 637DF21F194 for ; Mon, 3 Jun 2013 01:57:40 -0700 (PDT) X-Spam-Status: No, hits=4.1 required=6.5 tests=AWL: 0.034,BAYES_99: 4.07,TOTAL_SCORE: 4.104,autolearn=no X-Spam-Level: **** X-Footer: bWVkaWFzcG90Lm5ldA== Received: from exchange.mediaspot.net ([192.168.0.22]) by mail.mediaspot.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 3 Jun 2013 10:57:37 +0200 Received: from EXCHANGE.mediaspot.local ([fe80::d853:1561:649a:ab52]) by EXCHANGE.mediaspot.local ([fe80::d853:1561:649a:ab52%6]) with mapi id 14.03.0123.003; Mon, 3 Jun 2013 10:57:37 +0200 From: Alessandro Bolletta To: Jaume Barcelo Thread-Topic: [Codel] testbed for testing fq_codel on wifi doesn't work as expected Thread-Index: Ac5ettHg6XhMKRJFSj+2M16tkjJp0gBbUnQAAAQ7l4D//+FMgP//3fmQ Date: Mon, 3 Jun 2013 08:57:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.76] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codel@lists.bufferbloat.net" Subject: [Codel] R: testbed for testing fq_codel on wifi doesn't work as expected X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 08:57:41 -0000 Yes, what you're saying is right, because only TCP can scale down the windo= w size in order to lower down his throughput when a packet loss is matched,= so a TCP flow can correctly handle a packet loss event and resend the lost= packet while decreasing the window size through his ARQ protocol.=20 So, it's true that CoDel is primarily developed in function of TCP, but it = is also true that fq_codel doesn't know what packet is dropping when happen= s that the queue fills out, simply because I'm configuring fq_codel to be t= he default qdisc for my ethernet interfaces. In conclusion, if I send a large UDP data flow without an application-layer= ARQ protocol and filling the queue, the data trasmitted will be unreliable= , because of packet loss generated by fq_codel, but I shouldn't experience = bufferbloat.=20 And this is what matters for me :) -- Alessandro Bolletta Mediaspot S.r.l. -----Messaggio originale----- Da: Jaume Barcelo [mailto:jaume.barcelo@upf.edu]=20 Inviato: luned=EC 3 giugno 2013 10.44 A: Alessandro Bolletta Oggetto: Re: [Codel] testbed for testing fq_codel on wifi doesn't work as e= xpected >From what I read, the idea is to drop packets to signal the TCP flows to sl= ow down. Why don't you try to saturate the flow using TCP? (iperf, or scp a large file) The Codel paper starts by explaining the behaviour of TCP in the bottleneck= . That's why I suspect that codel (and aqm in general) works only with TCP. Cheers! Jaume On Mon, Jun 3, 2013 at 10:35 AM, Alessandro Bolletta wrote: > Hi Jaume, > > the dropping technique should involve every type of packet fulling the qu= eue, including UDP packets. > It seems that there's something wrong with my configuration. > > -- > Alessandro Bolletta > Mediaspot S.r.l. > > -----Messaggio originale----- > Da: Jaume Barcelo [mailto:jaume.barcelo@upf.edu] > Inviato: luned=EC 3 giugno 2013 10.32 > A: Alessandro Bolletta > Oggetto: Re: [Codel] testbed for testing fq_codel on wifi doesn't work=20 > as expected > > Hi Alessandro, > > I am a newbie here. I wanted to ask why do you use udp to saturate the li= nk. I thought that codel was meant to throttle tcp flows. > > Cheers, > Jaume > > On Sat, Jun 1, 2013 at 1:09 PM, Alessandro Bolletta wrote: >> Hi everybody, >> >> I made a little testbed in my office with 2 Ubiquiti Nanobridge M5=20 >> and >> 2 TPlink 741nd. >> >> Nanobridges are simply connected in AP-STA mode and relaying traffic=20 >> to the two TPLinks where i'm running batman-adv. So I bridged the=20 >> bat0 interface create by batman-adv with one of the ethernet ports=20 >> offered by the ar71xx CPU. So I connected two laptops to the bridge=20 >> at both ends and I pushed up a bidirectional UDP flow filling the=20 >> wifi link available bandwidth (I saw that it constantly runs at 33Mbps i= n download and 37Mbps in upload). >> >> In every device (tplinks and ubnts) i'm running OpenWRT BARRIER=20 >> BREAKER (Bleeding Edge, r36692), running on kernel 3.8.12 >> >> I executed Dave Taht's debloat script for bash (and also the=20 >> lua-compatible >> one) on every device, but if i try to make a ping starting from a=20 >> laptop to the opposite laptop, these are the times that I get (sorry,=20 >> it's written in italian. "Richiesta scaduta" means "expired reply"): >> >> >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D259ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D281ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D285ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D91ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D130ms TTL=3D128 >> >> Richiesta scaduta. >> >> Richiesta scaduta. >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D251ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D188ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D156ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D279ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D314ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D288ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D324ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D297ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D318ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D301ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D115ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D312ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D292ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D266ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D227ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D91ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D266ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D190ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D161ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D132ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D118ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D166ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D247ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D281ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D282ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D288ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D165ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D251ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D307ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D294ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D297ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D275ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D288ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D282ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D273ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D224ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D159ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D103ms TTL=3D128 >> >> Richiesta scaduta. >> >> Richiesta scaduta. >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D186ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D225ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D299ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D112ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D171ms TTL=3D128 >> >> Richiesta scaduta. >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D175ms TTL=3D128 >> >> Richiesta scaduta. >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D147ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D211ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D279ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D279ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D228ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D219ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D167ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D177ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D197ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D265ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D275ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D237ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D237ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D285ms TTL=3D128 >> >> Richiesta scaduta. >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D166ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D262ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D275ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D30ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D84ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D249ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D244ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D201ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D110ms TTL=3D128 >> >> Richiesta scaduta. >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D220ms TTL=3D128 >> >> Risposta da 192.168.2.25: byte=3D32 durata=3D240ms TTL=3D128 >> >> >> >> >> >> While if I ping while i'm not doing traffic at all I get 1ms RTT=20 >> replies without packet loss. >> >> Can you help me to find the cause of this bufferbloat? >> >> >> >> Thanks >> >> Alessandro >> >> >> _______________________________________________ >> Codel mailing list >> Codel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/codel >> > >