From: Jarek Poplawski <jarkao2@gmail.com>
To: Patrick McHardy <kaber@trash.net>
Cc: Simon Horman <horms@verge.net.au>,
netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
Martin Devera <devik@cdi.cz>
Subject: Re: Possible regression in HTB
Date: Wed, 8 Oct 2008 00:00:22 +0200 [thread overview]
Message-ID: <20081007220022.GA2664@ami.dom.local> (raw)
In-Reply-To: <48EB5A92.6010704@trash.net>
Patrick McHardy wrote, On 10/07/2008 02:48 PM:
> Jarek Poplawski wrote:
>>>> Prior to this patch the result looks like this:
>>>>
>>>> 10194: 545134589bits/s 545Mbits/s
>>>> 10197: 205358520bits/s 205Mbits/s
>>>> 10196: 205311416bits/s 205Mbits/s
>>>> -----------------------------------
>>>> total: 955804525bits/s 955Mbits/s
>>>>
>>>> And after the patch the result looks like this:
>>>> 10194: 384248522bits/s 384Mbits/s
>>>> 10197: 284706778bits/s 284Mbits/s
>>>> 10196: 288119464bits/s 288Mbits/s
>>>> -----------------------------------
>>>> total: 957074765bits/s 957Mbits/s
>
> I've misinterpreted the numbers, please disregard my previous mail.
>
> I'm wondering though, even before this patch, the sharing doesn't
> seem to be proportional to the allocated rates. Assuming the upper
> limit is somewhere around 950mbit, we have 250 mbit for sharing
> above the allocated rates, so it should be:
>
> 500mbit class: 500mbit + 250mbit/7*5 == 678.57mbit
> 100mbit class: 100mbit + 250mbit/1*5 == 150mbit
> 100mbit class: 100mbit + 250mbit/1*5 == 150mbit
>
> But maybe my understanding of how excess bandwidth is distributed
> with HTB is wrong.
Good point, but the numbers a bit wrong:
500mbit class: 500mbit + 250mbit/7*5 == 678.57mbit
100mbit class: 100mbit + 250mbit/7*1 == 135.71mbit
100mbit class: 100mbit + 250mbit/7*1 == 135.71mbit
==========
950.00mbit
>
> I still can't really make anything of this bug, but the only two
> visible differences to HTB resulting from requeing on an upper level
> should be that
>
> 1) it doesn't reactivate classes that went passive by the last dequeue
> 2) the time checkpoint from the last dequeue event is different
>
> I guess its in fact the second thing, if a lower priority packet
> is requeued and dequeued again, HTB doesn't notice and might allow
> the class to send earlier again than it would have previously.
With high requeuing the timing has to be wrong, but I'm not sure why
just lower priority has to gain here.
Anyway, IMHO this regression is really doubtful: since the digits are
wrong in both cases I can only agree the old method gives better wrong
results...
Jarek P.
next prev parent reply other threads:[~2008-10-07 21:58 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 [this message]
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
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=20081007220022.GA2664@ami.dom.local \
--to=jarkao2@gmail.com \
--cc=davem@davemloft.net \
--cc=devik@cdi.cz \
--cc=horms@verge.net.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).