From: Simon Horman <horms@verge.net.au>
To: Jarek Poplawski <jarkao2@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>,
netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
Martin Devera <devik@cdi.cz>
Subject: Re: Possible regression in HTB
Date: Thu, 9 Oct 2008 11:54:40 +1100 [thread overview]
Message-ID: <20081009005437.GA6342@verge.net.au> (raw)
In-Reply-To: <20081008080340.GE4174@ff.dom.local>
On Wed, Oct 08, 2008 at 08:03:40AM +0000, Jarek Poplawski wrote:
> On Wed, Oct 08, 2008 at 06:22:04PM +1100, Simon Horman wrote:
> > On Wed, Oct 08, 2008 at 06:55:51AM +0000, Jarek Poplawski wrote:
> > > On Wed, Oct 08, 2008 at 02:31:26AM +0200, Patrick McHardy wrote:
> > > ...
> > > > I'm pretty sure that the differences are caused by HTB not being
> > > > in control of the queue since the device is the real bottleneck
> > > > in this configuration.
> > >
> > > Yes, otherwise there would be no requeuing. And, btw. the golden rule
> > > of scheduling/shaping is limiting below "hardware" limits.
> > >
> > > > Its quite possible that there simply might
> > > > a subtle timing change that causes feedback through HTBs borrowing
> > > > and ceiling.
> > >
> > > I'd add my previous suspicion there could be not enough enqeuing on
> > > time for the fastest class (could be also very bursty), so other
> > > classes can borrow more.
> > >
> > > >
> > > > So what would really be useful to understand this is to make HTB
> > > > control the queue and see if it behaves as expected.
> > > >
> > >
> > > Right, trying with lower rates/ceils should explain this.
> >
> > As I mentioned earlier things seem to work quite well with lower
> > rates/ceilings. When I set up the classes with 10x lower values
> > for rate and celing, as follows:
> >
> >
> > [ rate=100Mbit/s ]
> > [ ceil=100Mbit/s ]
> > |
> > +--------------------+--------------------+
> > | | |
> > [ rate= 50Mbit/s ] [ rate= 10Mbit/s ] [ rate= 10Mbit/s ]
> > [ ceil=100Mbit/s ] [ ceil=100Mbit/s ] [ ceil= 100Mbit/s ]
> >
> > Then I get results that are fairly close to the ideal values.
> >
> > net-next-2.6 - d877984
> > ----------------------
> > 10194: 68075482bits/s 68Mbits/s
> > 10197: 14464848bits/s 14Mbits/s
> > 10196: 14465632bits/s 14Mbits/s
> > -----------------------------------
> > total: 97005962bits/s 97Mbits/s
> >
> > And I get those kind of results consistently for various
> > different kernel versions.
>
> OK. But as Patrick mentioned it would be interesting to try a little
> below hardware limits: 950, or maybe lower, until HTB starts getting
> accuracy.
Hi,
it seems that for my particular setup the magic number is 935Mbit/s.
Kernel is net-next-2.6 071d7ab6649eb34a873a53e71635186e9117101d
("ipvs: Remove stray file left over from ipvs move"),
which is after Jarek's "pkt_sched: Update qdisc requeue stats in
dev_requeue_skb()" patch.
ideal (based on 950Mbit/s aggregate)
500mbit class (10194): 500mbit + 250mbit/7*5 == 678.57mbit
100mbit class (10196): 100mbit + 250mbit/7*1 == 135.71mbit
100mbit class (10197): 100mbit + 250mbit/7*1 == 135.71mbit
==========
950.00mbit
n=900
10194: 677727637bits/s 677Mbits/s
10197: 136662048bits/s 136Mbits/s
10196: 136725637bits/s 136Mbits/s
-----------------------------------
total: 951115322bits/s 951Mbits/s
n=920
10194: 676271338bits/s 676Mbits/s
10197: 137301090bits/s 137Mbits/s
10196: 137301877bits/s 137Mbits/s
-----------------------------------
total: 950874306bits/s 950Mbits/s
n=930
10194: 674681581bits/s 674Mbits/s
10197: 137538965bits/s 137Mbits/s
10196: 137541320bits/s 137Mbits/s
-----------------------------------
total: 949761866bits/s 949Mbits/s
n=933
10194: 675568704bits/s 675Mbits/s
10197: 137661437bits/s 137Mbits/s
10196: 137662221bits/s 137Mbits/s
-----------------------------------
total: 950892362bits/s 950Mbits/s
n=934
10194: 675399128bits/s 675Mbits/s
10197: 137653586bits/s 137Mbits/s
10196: 137704613bits/s 137Mbits/s
-----------------------------------
total: 950757328bits/s 950Mbits/s
n=935
10194: 675169893bits/s 675Mbits/s
10197: 137667714bits/s 137Mbits/s
10196: 137670858bits/s 137Mbits/s
-----------------------------------
total: 950508466bits/s 950Mbits/s
n=936
10194: 385295016bits/s 385Mbits/s
10197: 285078114bits/s 285Mbits/s
10196: 286588581bits/s 286Mbits/s
-----------------------------------
total: 956961712bits/s 956Mbits/s
n=937
10194: 384569616bits/s 384Mbits/s
10197: 285480072bits/s 285Mbits/s
10196: 286627050bits/s 286Mbits/s
-----------------------------------
total: 956676738bits/s 956Mbits/s
n=940
10194: 384577466bits/s 384Mbits/s
10197: 285655138bits/s 285Mbits/s
10196: 286846872bits/s 286Mbits/s
-----------------------------------
total: 957079477bits/s 957Mbits/s
n=950
10194: 384097789bits/s 384Mbits/s
10197: 285950325bits/s 285Mbits/s
10196: 286894760bits/s 286Mbits/s
-----------------------------------
total: 956942874bits/s 956Mbits/s
n=1000
10194: 384639482bits/s 384Mbits/s
10197: 285133069bits/s 285Mbits/s
10196: 287172674bits/s 287Mbits/s
-----------------------------------
total: 956945226bits/s 956Mbits/s
# HTB
###########################################################################
n=933
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 10 r2q $((n * 10))
tc class add dev eth0 parent 1: classid 1:1 htb \
rate ${n}Mbit ceil ${n}Mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb \
rate ${n}Mbit ceil ${n}Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb \
rate 500Mbit ceil ${n}Mbit
tc class add dev eth0 parent 1:1 classid 1:12 htb \
rate 100Mbit ceil ${n}Mbit
tc class add dev eth0 parent 1:1 classid 1:13 htb \
rate 100Mbit ceil ${n}Mbit
#tc filter add dev eth0 protocol ip parent 1: \
# u32 match ip src 172.17.60.194 flowid 1:11
#tc filter add dev eth0 protocol ip parent 1: \
# u32 match ip src 172.17.60.196 flowid 1:12
#tc filter add dev eth0 protocol ip parent 1: \
# u32 match ip src 172.17.60.197 flowid 1:13
tc filter add dev eth0 protocol ip parent 1: \
u32 match ip dport 10194 0xffff flowid 1:11
tc filter add dev eth0 protocol ip parent 1: \
u32 match ip dport 10196 0xffff flowid 1:12
tc filter add dev eth0 protocol ip parent 1: \
u32 match ip dport 10197 0xffff flowid 1:13
tc -s -d class show dev eth0
next prev parent reply other threads:[~2008-10-09 0:54 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-07 1:15 Possible regression in HTB Simon Horman
2008-10-07 4:51 ` Simon Horman
2008-10-07 7:44 ` Jarek Poplawski
2008-10-07 12:03 ` Patrick McHardy
2008-10-08 0:09 ` Simon Horman
2008-10-08 6:37 ` Jarek Poplawski
2008-10-08 7:22 ` Simon Horman
2008-10-08 7:53 ` Jarek Poplawski
2008-10-07 12:20 ` Jarek Poplawski
2008-10-07 12:48 ` Patrick McHardy
2008-10-07 22:00 ` Jarek Poplawski
2008-10-08 0:21 ` Simon Horman
2008-10-08 0:31 ` Patrick McHardy
2008-10-08 0:40 ` Patrick McHardy
2008-10-08 7:34 ` Martin Devera
2008-10-08 8:53 ` Jarek Poplawski
2008-10-08 10:47 ` Martin Devera
2008-10-08 12:04 ` Jarek Poplawski
2008-10-09 1:09 ` Simon Horman
2008-10-09 6:22 ` Martin Devera
2008-10-09 9:56 ` Jarek Poplawski
2008-10-09 10:14 ` Jarek Poplawski
2008-10-09 10:52 ` Martin Devera
2008-10-09 11:04 ` Jarek Poplawski
2008-10-09 11:11 ` Simon Horman
2008-10-09 11:22 ` Martin Devera
2008-10-08 6:55 ` Jarek Poplawski
2008-10-08 7:06 ` Denys Fedoryshchenko
2008-10-08 7:46 ` [PATCH] " Jarek Poplawski
2008-10-08 18:36 ` David Miller
2008-10-08 7:22 ` Simon Horman
2008-10-08 8:03 ` Jarek Poplawski
2008-10-09 0:54 ` Simon Horman [this message]
2008-10-09 6:21 ` Jarek Poplawski
2008-10-09 6:53 ` Martin Devera
2008-10-09 11:18 ` Simon Horman
2008-10-09 11:58 ` Patrick McHardy
2008-10-09 12:36 ` Jarek Poplawski
2008-10-10 6:59 ` Jarek Poplawski
2008-10-10 8:57 ` Jarek Poplawski
2008-10-10 12:12 ` Jarek Poplawski
2008-10-08 0:10 ` Simon Horman
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=20081009005437.GA6342@verge.net.au \
--to=horms@verge.net.au \
--cc=davem@davemloft.net \
--cc=devik@cdi.cz \
--cc=jarkao2@gmail.com \
--cc=kaber@trash.net \
--cc=netdev@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.