From: Andy Furniss <adf.lists@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: Query about tc configuration and associated network issues
Date: Mon, 15 Feb 2016 22:43:53 +0000 [thread overview]
Message-ID: <56C254A9.90802@gmail.com> (raw)
In-Reply-To: <20160215200607.Horde.Q4KQsnbmg5I5uPggYzCERU1@webmail.duth.gr>
Δημήτριος Μάστορας 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.
next prev parent reply other threads:[~2016-02-15 22:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-15 18:06 Query about tc configuration and associated network issues Δημήτριος Μάστορας
2016-02-15 22:43 ` Andy Furniss [this message]
2016-02-16 0:24 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56C254A9.90802@gmail.com \
--to=adf.lists@gmail.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.