netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: Vladimir Ivashchenko <hazard@francoudi.com>
Cc: Denys Fedoryschenko <denys@visp.net.lb>, netdev@vger.kernel.org
Subject: Re: bond + tc regression ?
Date: Mon, 18 May 2009 08:51:27 +0000	[thread overview]
Message-ID: <20090518085127.GA6636@ff.dom.local> (raw)
In-Reply-To: <1242586001.2711.11.camel@hazard2.francoudi.com>

On 17-05-2009 20:46, Vladimir Ivashchenko wrote:
>>> All child classes have smaller bursts than the parent. However, there are
>>> two sub-classes which have ceil at 70% of parent, e.g. ~500mbit each. I
>>> don't know HTB internals, perhaps these two classes make the parent class
>>> overstretch itself.
>> As i remember important to keep sum of child rates lower or equal parent rate.
>> Sure ceil of childs must not exceed ceil of parent.
>> Sometimes i had mess, when i tried to play with quantum value. After all that 
>> i switched to HFSC which works for me flawlessly. Maybe we should give more 
>> attention to HTB problem with high speeds and help kernel developers spot 
>> problem, if there is any.
> 
> In case of HFSC my problem is even worse. With 775mbit ceiling
> configured it is passing over 900mbit in reality. Moreover not having
> statistics for parent classes makes it difficult to troubleshoot :( I'm
> 100% sure that it is 900 mbps, I see this on the switch.
> 
> Attached is "tc -s -d class show dev bond0" output.
> 
> To calculate total traffic rate:
> 
> $ cat hfsc-stat.txt | grep rate | grep Kbit | sed 's/Kbit//' | awk
> '{ a=a+$2; } END { print a; }'
> 906955
> 
> Did I misconfigure something ?... How can hfsc go above 775mbit when
> everything goes via class 1:2 with 775mbit rate & ul ?

Maybe... It's a lot of checking - it seems test cases could be simpler
to show the real problem. Anyway, it looks like the sum of m2 of 1:2
children is more than 775Mbit.


>>> By the way, I experience the same "overstretching" with hfsc. In any case,
>>> I prefer HTB because it reports statistics of parent classes, unlike hfsc.
>> Sometimes it happen when some offloading enabled on devices.
>> Check ethtool -k device
> 
> Offload parameters for eth0:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp segmentation offload: off
> udp fragmentation offload: off

Current versions of ethtool should show "generic segmentation offload"
too.

I hope you've read the nearby thread "HTB accuracy for high speed",
which explains at least partially some problems/bugs, and maybe you'll
try some patches too (at last one of them addresses the problem you've
reported). Anyway, if you don't find hfsc is better for you I'd be
more interested in tracking this on htb test cases yet.

Thanks,
Jarek P.

  reply	other threads:[~2009-05-18  8:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-05 15:45 bond + tc regression ? Vladimir Ivashchenko
2009-05-05 16:25 ` Denys Fedoryschenko
2009-05-05 16:31 ` Eric Dumazet
2009-05-05 17:41   ` Vladimir Ivashchenko
2009-05-05 18:50     ` Eric Dumazet
2009-05-05 23:50       ` Vladimir Ivashchenko
2009-05-05 23:52         ` Stephen Hemminger
2009-05-06  3:36         ` Eric Dumazet
2009-05-06 10:28           ` Vladimir Ivashchenko
2009-05-06 10:41             ` Eric Dumazet
2009-05-06 10:49               ` Denys Fedoryschenko
2009-05-06 18:45           ` Vladimir Ivashchenko
2009-05-06 19:30             ` Denys Fedoryschenko
2009-05-06 20:47               ` Vladimir Ivashchenko
2009-05-06 21:46                 ` Denys Fedoryschenko
2009-05-08 20:46                   ` Vladimir Ivashchenko
2009-05-08 21:05                     ` Denys Fedoryschenko
2009-05-08 22:07                       ` Vladimir Ivashchenko
2009-05-08 22:42                         ` Denys Fedoryschenko
2009-05-17 18:46                           ` Vladimir Ivashchenko
2009-05-18  8:51                             ` Jarek Poplawski [this message]
2009-05-06  8:03       ` Ingo Molnar
2009-05-06  6:10     ` Jarek Poplawski
2009-05-06 10:36       ` Vladimir Ivashchenko
2009-05-06 10:48         ` Jarek Poplawski
2009-05-06 13:11           ` Vladimir Ivashchenko
2009-05-06 13:31             ` Patrick McHardy

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=20090518085127.GA6636@ff.dom.local \
    --to=jarkao2@gmail.com \
    --cc=denys@visp.net.lb \
    --cc=hazard@francoudi.com \
    --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).