Re: Query about tc configuration and associated network issues

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <adf.lists@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux