From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by lists.bufferbloat.net (Postfix) with ESMTPS id 44E7D3C9F3 for ; Sun, 17 Jan 2016 19:45:51 -0500 (EST) Received: by mail-yk0-x231.google.com with SMTP id x67so599426459ykd.2 for ; Sun, 17 Jan 2016 16:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=otvorenamreza-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=E+by5b2/6gtnCYqWQE7lUJYx2A5uXaxNwd6pbfl398c=; b=Ie7r2IKgKWLUMr/8+hoxrimgAwKqC49cXtmvzbDdNzqCojkfO9QIo+r5tfF5yfUTey ru/3OBLu9tKLSn1px8NJVmHpbrKupelnQmWk2DKRKjVS0ZGg9spMDo7f4jzaU7x4FslU I2XwBHyz3cRgzagXlb/13C+F3TZQv40p30Lmd9vOhmDops4gsKOty/YlL4c3PnICbS4o Z9R9zeRve3hLVDwoAvMOupq2wmCugT+hh+ZDO0H3AE0k4KtTj2suN9ySXloUVTTw9DL6 DpHCQUh8BTAjHvb1CcLmz7QwudGkiUiavsEo9niM7t5u8Zk57rS67FvbSBYu39XZWuzf TF7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=E+by5b2/6gtnCYqWQE7lUJYx2A5uXaxNwd6pbfl398c=; b=LZnAUntDHsv2dkC7JVcp94bzExZxKdsU2BEU5mws7QWU1Jh/5RefRc7cVCk2AIdSOr 6m7ctM2mBX18wIsZ19JgtkunJnQM8UtIt7gah5RAaIz1pWakLk7zviHXAaC4J6m/3fYY PtzQKT0ofnR4oaWSywToxvE+pxL6eWmW0DpWe7qA+tZBVMDbLnFQghA9M4P3hHFcVQ3S DjZy/njG5XnVqm8ZG6D2cmSDXe69784oRcqc1jEVFWkuALDlobULo1qWCsPM2HeMHpVV GXOVigow2wp7qLK6uLg5j/GWxYdWenktTJS+P+6mjzUO65Rc9q4FTfBza0BxVHBIcru6 CXyg== X-Gm-Message-State: ALoCoQkTO3DUtVmFmJ6BjQAKM6XVzGtDBdbkgOffnOiVOgeyPCVqX8l9z9FIGAteE/7D+jRB8Vv1Dtluxabm5wNC7mfrlR+qDQ== X-Received: by 10.13.217.151 with SMTP id b145mr15218770ywe.226.1453077950865; Sun, 17 Jan 2016 16:45:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.114.7 with HTTP; Sun, 17 Jan 2016 16:45:11 -0800 (PST) X-Originating-IP: [93.143.151.104] In-Reply-To: References: From: Valent Turkovic Date: Mon, 18 Jan 2016 01:45:11 +0100 Message-ID: To: Outback Dingo Cc: Dave Taht , "cerowrt-devel@lists.bufferbloat.net" , make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] routers you can throw off the back of a truck X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 00:45:52 -0000 Hi everybody, our mission is to provide internet in humanitarian and crisis situations to as many people as possible, and to make bandwidth fairly distributed between users and to have low bufferbloat. Issue with working out in crisis stations is that you don't know what kind of uplink you will get, and bandwidth you get is much often variable than constant. I have tested 3G/4G uplinks and download can be in and range from 100Mbps to 5 Mbps, especially with mobile nodes (we sometimes put router, battery and 3G/4G modem in backpack and go where it is needed). Is there anyway to configure any queuing technique in Linux kernel that so it distributes bandwidth equally between users and to keep lag (bufferbloat) as low as possible, but without needing to define absolute values for download and upload. For bandwidth distribution I know that Mikrotik has really awesome technique called PCQ [1] and AFAIK there is no technique as PCQ in Linux kernel, the closes I have found is SFQ, if you know any other similar queueing techniques in Linux kernel please share. I have been testing different queue setup scripts for fq_codel in OpenWrt, to see how they work with properly setup bandwidth limits and also with completely wrong bandwidth limits. Test have been done with 3G/4G USB modems and on 100/10 Mbps fibre optics connection with TP-LINK WDR3600 router running latest Chaos Calmer OpenWrt. Also I have also seen that pfSense mentions that HFSC [2] that is "very effective for VoIP on links that degrade quickly, such as 3G/4G, but it can be complex to configure and tweak for proper operation." so I tested HFSC queuing technique with fq_codel with and results show that it also doesn't work if bandwith is not configured correctly So far all fq_codel + queue setup scripts on OpenWrt I have tested give low bufferbloat results only when banddwidth is configured to around 90% of available bandwidth, once I setup it to 200% of available bandwidth I get really bad bufferbloat results, so any current options just don't work if bandwidth changes. Please don't assume I know anything, if you have any idea what I could test or how to get better results in real world conditions please share... Here are my current results it they are interesting to anybody. Fiber connection 100/10 Mbps no qos: 150/110 ms - 94/10.4 Mbps - http://www.dslreports.com/speedtest/263= 5531 no qos: 235/132 ms - 94.2/10.4 Mbps - http://www.dslreports.com/speedtest/2635586 no qos: 160/130 ms - 96.8/10.5 Mbps - http://www.dslreports.com/speedtest/2635646 Fiber connection: SQM 95000/9500 on eth0.2 fq_codel + nxt_routed_hfsc.qos: 203/42 ms - 95.2/7.2 Mbps - http://www.dslreports.com/speedtest/2629376 fq_codel + layer_cake.qos: 193/135 ms - 93.1/7.7 Mbps - http://www.dslreports.com/speedtest/2629461 fq_codel + layer_cake.qos: 201/116 ms - 93.6/8.2 Mbps - http://www.dslreports.com/speedtest/2629502 Fiber connection: 100/10 Mbps - SQM 90/9 Mbps (90000/9000) on eth0.2 fq_codel + simple: 63/58 ms - 83/4 Mbps - http://www.dslreports.com/speedtest/2629696 fq_codel + simple: 87/55 ms - 84.2/4.6 Mbps - http://www.dslreports.com/speedtest/2629939 fq_codel + nxt_routed_hfsc: 130/46 ms - 94.6/6.9 Mbps - http://www.dslreports.com/speedtest/2630019 fq_codel + nxt_routed_hfsc: 160/38 ms - 93/9.1 Mbps - http://www.dslreports.com/speedtest/2630082 fq_codel + layer_cake: 140/120 ms - 91.3/6.6 Mbps - http://www.dslreports.com/speedtest/2629597 fq_codel + layer_cake: 140/190 ms - 92.5/10.2 Mbps - http://www.dslreports.com/speedtest/2630122 fq_codel + simplest: 41/35 ms - 81.4/3.7 Mbps - http://www.dslreports.com/speedtest/2629988 fq_codel + simplest: 57/56 ms - 84.5/8.8 Mbps - http://www.dslreports.com/speedtest/2630228 fq_codel + piece_of_cake: 175/119 ms - 93/7.5 Mbps - http://www.dslreports.com/speedtest/2629749 fq_codel + piece_of_cake: 215/146 ms - 89.6/11.7 Mbps - http://www.dslreports.com/speedtest/2630294 fq_codel + simple_pppoe: 61/48 ms - 84.1/8.5 Mbps - http://www.dslreports.com/speedtest/2630153 Fiber connection: 100/10 Mbps - SQM 200/20 Mbps (200000/20000) on eth0.2 fq_codel + simple: 102/132 ms - 94.8/10.3 Mbps - http://www.dslreports.com/speedtest/2630347 fq_codel + nxt_routed_hfsc: 150/133 ms - 94.1/10.5 Mbps - http://www.dslreports.com/speedtest/2630386 fq_codel + simplest: 178/148 ms - 92.7/10.5 Mbps - http://www.dslreports.com/speedtest/2630488 fq_codel + piece_of_cake: 192/122 ms - 95/10.7 Mbps - http://www.dslreports.com/speedtest/2635507 Cheers, Valent. [1] http://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ [2] https://doc.pfsense.org/index.php/Traffic_Shaping_Guide On Sun, Jan 17, 2016 at 9:31 PM, Outback Dingo wro= te: > > > On Sun, Jan 17, 2016 at 7:46 PM, Dave Taht wrote: >> >> http://www.meshpoint.me/ design and purpose seems very cool. >> >> Given all the nifty new autoconfig stuff in homenet like hnetd and >> source specific babel - perhaps we are closer than ever before to >> actually being able to throw this kind off stuff off the back of a >> truck and have it "just work". >> >> If only we had bufferbloat-free lte uplink hardware (has any >> materialized, perhaps in a mini-pci-e form factor?) >> >> It does now seem semi-possible to hack on enodeBs nowadays: >> >> http://bellard.org/lte/ >> >> Are any LTE providers supporting dhcp-pd or some equivalent for >> getting routable ipv6 subnets? >> >> -- >> Dave T=C3=A4ht >> Let's go make home routers and wifi faster! With better software! > > > There have been "numerous" autoconfiguration setups deployed on OpenWRT b= y a > few different people, even myself > adding in 4G/LTE would be nice, though this has been possible for a while= , > even ive used the BladeRF in a "BTS" environment > for testing of WhiteSpace wireless VOIP, and Disaster Scenerios, grab an > Alix APU load OpenWRT, plug a bladeRF into the USB > load OpenBTS on it and place it out in the wild.... Instant white space > telco > > >> >> https://www.gofundme.com/savewifi >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > >