All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Rabbitson <rabbit+list@rabbit.us>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] TC (HTB) doesn't work well when network is congested?
Date: Fri, 26 Oct 2007 22:39:58 +0000	[thread overview]
Message-ID: <47226CBE.5070503@rabbit.us> (raw)
In-Reply-To: <4720C673.7040900@max-t.com>

William Xu wrote:
> Hi Peter, thanks for looking at this.
> 
> Here are the information I got after running tests. The client1 got 
> 7MB/s instead of 40MB/s for SEND,
> and 40MB/s for RECV during the test.
> 
> Thanks,
> william
> 
> # ip link show
> 
> ...
> 5: eth2: <BROADCAST,MULTICAST,UP,LUP> mtu 9000 qdisc htb qlen 1000
>    link/ether 00:e0:ed:04:9f:a2 brd ff:ff:ff:ff:ff:ff
> ...
> 12: ifb0: <BROADCAST,NOARP,UP,LUP> mtu 9000 qdisc htb qlen 32
>    link/ether f2:f2:77:f9:cf:30 brd ff:ff:ff:ff:ff:ff
> 
> #tc qdisc show
> qdisc pfifo_fast 0: dev eth0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 
> 1 1 1 1 1
> qdisc ingress ffff: dev eth2 ----------------
> qdisc htb 1: dev eth2 r2q 100 default 30 direct_packets_stat 0
> qdisc pfifo_fast 0: dev eth3 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 
> 1 1 1 1 1
> qdisc pfifo_fast 0: dev eth4 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 
> 1 1 1 1 1
> qdisc pfifo_fast 0: dev eth5 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 
> 1 1 1 1 1
> qdisc pfifo_fast 0: dev eth6 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 
> 1 1 1 1 1
> qdisc pfifo_fast 0: dev eth7 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 
> 1 1 1 1 1
> qdisc pfifo_fast 0: dev eth8 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 
> 1 1 1 1 1
> qdisc htb 1: dev ifb0 r2q 100 default 30 direct_packets_stat 0
> 
> #tc -s -d class show dev ifb0
> class htb 1:10 parent 1:1 prio 0 quantum 200000 rate 320000Kbit ceil 
> 960000Kbit burst 169000b/64 mpu 0b overhead 0b cburst 489000b/64 mpu 0b 
> overhead 0b level 0
> Sent 2366125838 bytes 928639 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> lended: 925807 borrowed: 2832 giants: 0
> tokens: 4224 ctokens: 4075
> 
> class htb 1:1 root rate 960000Kbit ceil 960000Kbit burst 489000b/64 mpu 
> 0b overhead 0b cburst 489000b/64 mpu 0b overhead 0b level 7
> Sent 36927678674 bytes 6132723 pkt (dropped 0, overlimits 0 requeues 0)
> rate 2672bit 1pps backlog 0b 0p requeues 0
> lended: 1131873 borrowed: 0 giants: 0
> tokens: 4074 ctokens: 4074
> 
> class htb 1:30 parent 1:1 prio 1 quantum 200000 rate 640000Kbit ceil 
> 960000Kbit burst 328960b/64 mpu 0b overhead 0b cburst 489000b/64 mpu 0b 
> overhead 0b level 0
> Sent 34561552836 bytes 5204084 pkt (dropped 44, overlimits 0 requeues 0)
> rate 528bit 0pps backlog 0b 0p requeues 0
> lended: 4075043 borrowed: 1129041 giants: 0
> tokens: 4108 ctokens: 4074
> 
> #tc -s -d class show dev eth2
> class htb 1:10 parent 1:1 prio 0 quantum 200000 rate 320000Kbit ceil 
> 960000Kbit burst 169000b/64 mpu 0b overhead 0b cburst 489000b/64 mpu 0b 
> overhead 0b level 0
> Sent 12092794712 bytes 1544210 pkt (dropped 0, overlimits 0 requeues 0)
> rate 56bit 0pps backlog 0b 0p requeues 0
> lended: 1543687 borrowed: 523 giants: 0
> tokens: 4224 ctokens: 4075
> 
> class htb 1:1 root rate 960000Kbit ceil 960000Kbit burst 489000b/64 mpu 
> 0b overhead 0b cburst 489000b/64 mpu 0b overhead 0b level 7
> Sent 36872760531 bytes 7346321 pkt (dropped 0, overlimits 0 requeues 0)
> rate 288bit 0pps backlog 0b 0p requeues 0
> lended: 40477 borrowed: 0 giants: 0
> tokens: 4073 ctokens: 4073
> 
> class htb 1:30 parent 1:1 prio 1 quantum 200000 rate 640000Kbit ceil 
> 960000Kbit burst 328960b/64 mpu 0b overhead 0b cburst 489000b/64 mpu 0b 
> overhead 0b level 0
> Sent 24779965819 bytes 5802111 pkt (dropped 0, overlimits 0 requeues 0)
> rate 176bit 0pps backlog 0b 0p requeues 0
> lended: 5762157 borrowed: 39954 giants: 0
> tokens: 4109 ctokens: 4073
> 
> 

The setup looks good. There are only two things that come to mind - you 
have problems with TSO, or your clock is too slow. For the first use 
ethtool -K to disable all 6 offloading parameters. For the second check 
what is the value of CONFIG_HZ in the current kernel config 
(/boot/config-<your-kernel-version>), and if it is less than 1000 this 
might be your problem as well. If none of those help - I am out of 
ideas, hopefully someone else can help you.

Peter
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  parent reply	other threads:[~2007-10-26 22:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-25 16:38 [LARTC] TC (HTB) doesn't work well when network is congested? William Xu
2007-10-25 17:22 ` Peter Rabbitson
2007-10-25 18:20 ` William Xu
2007-10-25 21:13 ` Peter Rabbitson
2007-10-26 13:44 ` William Xu
2007-10-26 22:39 ` Peter Rabbitson [this message]
2007-10-31 19:39 ` William Xu
2007-11-01 12:08 ` Georgi Alexandrov

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=47226CBE.5070503@rabbit.us \
    --to=rabbit+list@rabbit.us \
    --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.