Δημήτριος Μάστορας 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. -- 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
