From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Taht Date: Tue, 16 Feb 2016 00:24:53 +0000 Subject: Re: Query about tc configuration and associated network issues Message-Id: List-Id: References: <20160215200607.Horde.Q4KQsnbmg5I5uPggYzCERU1@webmail.duth.gr> In-Reply-To: <20160215200607.Horde.Q4KQsnbmg5I5uPggYzCERU1@webmail.duth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: lartc@vger.kernel.org Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi On Mon, Feb 15, 2016 at 2:43 PM, Andy Furniss wrote: > Δημήτριος Μάστορας wrote: >> >> Hello, >> >> I work on a master thesis project regarding broadband connection >> sharing. My network topology is as follows: 1. A PC which is >> connected to the Internet via eth0 and shares its connection with >> other computers via wlan0 (as a hotspot). 2. Two laptops serving as >> traffic generators connected to the hotspot through WiFi. 3. A PC >> serving as a traffic sink. >> >> I’m using the D-ITG traffic generator to emulate HTTP traffic. One of >> the laptops runs ITGSend in multi-flow mode to generate >> simultaneously several flows(e.g. 100 flows) whose traffic is >> delivered to the sink (3) which runs ITGRecv. >> >> I have tested this scenario without having any tc rules [qdisc, >> class, filter] applied, and it works fine. >> >> The problem I'm facing is that when I am setting a bandwidth limit >> (downlink: 10Mbps, uplink:200Kbps) and testing different queueing >> configurations(for example HTB, prio) (see the attached file - SBS), >> ITGRecv gives me an error and drops the connection. >> >> Given that without any tc rules applied my system works fine, I’m >> guessing that tc is affecting D-ITG somehow. After some researching I >> wasn’t able to pin point what is the issue. For example, my initial >> guess was the due to the limited bandwidth, lots of out of order >> packets were delivered to the sink, or IP fragmentation could be the >> issue, but I wasn't able to verify any of these assumptions through >> netstat –sa. >> >> Does anyone have any idea what the problem could be? Is anything >> wrong with my tc configuration? Is there any chance that a kernel >> configuration might solve the issue? > > > arp will go to htb default unless you filter elsewhere and yours is only > 10kbit. I've never tested pfifo_fast with htb - maybe it doesn't help > arp, plus its length may depend on the txqlen of the $IF - maybe for > testing consistency it would be better to use queues that you choose the > length/behavior of and don't forget about arp. > > With htb if no default is used, unclassified goes unshaped - which is > nice for arp. > > HFSC is different, unclassified is dropped, so not so good if arp is > unclassified. > > wondershaper was flawed because you have make sure child bandwidths add > up to parents. Leverage sqm-scripts for your tests. http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die > > > -- > To unsubscribe from this list: send the line "unsubscribe lartc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html