From: William Xu <wxu@max-t.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] TC (HTB) doesn't work well when network is congested?
Date: Thu, 25 Oct 2007 18:20:43 +0000 [thread overview]
Message-ID: <4720DE7B.10404@max-t.com> (raw)
In-Reply-To: <4720C673.7040900@max-t.com>
Thanks, Peter,
So what you means is that network congestion caused my problem. I test
the bandwidth
between client1 and server using iperf, SEND and RECV are both 122MB/s.
I tried
different values for the total bandwidth, and I got the following numbers:
total bandwidth 120MB/s client1 SEND :10MB/s RECV :39MB/s
total bandwidth 110MB/s client1 SEND :16MB/s RECV :40MB/s
total bandwidth 100MB/s client1 SEND :30MB/s RECV :38MB/s
total bandwidth 90MB/s client1 SEND :39MB/s RECV :40MB/s
total bandwidth 80MB/s client1 SEND :39MB/s RECV :40MB/s
total bandwidth 70MB/s client1 SEND :40MB/s RECV :40MB/s
total bandwidth 60MB/s client1 SEND :40MB/s RECV :40MB/s
So TC works well as long as total bandwidth is below 90MB/s, which is
about 70% of the
wise speed. Is it possible that I can use the full bandwidth (122MB/s)
in my script?
william
Peter Rabbitson wrote:
> William Xu wrote:
>
>> Hi,
>>
>> I have a server and ten clients in a Gigabit network. The server has
>> 125mbps network bandwidth.
>> I want that the server has 40Mbps bandwidth reserved for client 1 (IP
>> 192.168.5.141), and the
>> rest bandwidth is for all other clients.
>>
>> <snip>
>>
>> I ran a test in which all 10 clients send/receive packets to/from the
>> server simultaneously. But
>> Client 1 only got 20mbps bandwidth for sending, and 38mpbs for
>> receiving. If I limit the rate of
>> both classes 1:1 to 60mbps instead of 125mbps, Client 1 got 39mbps
>> for sending, and 40mbps for
>> receiving.
>>
>> I am not sure what might cause this. Is it because TC doesn't work
>> well when network is congested?
>> Or my script is not right?
>>
>
> No network will be able to operate at its theoretical maximum. In the
> case of a gigabit network you will be lucky to get consistent 120mbps,
> and it heavily depends on the hardware quality, and the number of
> switches in between. So what you are doing is oversaturating the link,
> the ACK packets can not get through, your speed drops due to
> delays/retransmissions. Perform a test with only two systems sending
> stuff to each other to see what is the actual bandwidth you can hope
> for, and use that number instead of 125mbps.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2007-10-25 18:20 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 [this message]
2007-10-25 21:13 ` Peter Rabbitson
2007-10-26 13:44 ` William Xu
2007-10-26 22:39 ` Peter Rabbitson
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=4720DE7B.10404@max-t.com \
--to=wxu@max-t.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox