Prev: following wpa_supplicant negotiations.
Next: Unable to use stunnel with tin...
From: Dances With Crows on 14 Jun 2008 13:25
So I thought I'd limit the bandwidth on one of my network interfaces to
run a few tests on a few things. I tried:

tc qdisc add dev eth1 root tbf burst 20480 limit 20480 \
mtu 1514 rate 32000bps

....as was mentioned in the Traffic Control HOWTO. However, sustained
transfer rates weren't 64K/sec, but were 15K/sec. Doubling and
quadrupling the numbers for rate, burst, and limit made no difference to
the sustained transfer rates I observed.

Kernel 2.6.22.1 (vanilla), iproute2 2.6.22.20070710 . Is the HOWTO
outdated? Am I doing something stupid? Is there an easier way? The
machines are using forcedeth and e1000 cards, and sustained transfer
rates without tc are ~10M/sec. If you need more information, say what
you need and I'll find it. Thanks in advance.

(I ended up limiting bandwidth with an old 10bT DEC Tulip card I had
lying around. Yay for obsolete hardware, I guess.)

--
"Depress the button," it said. Gloria looked at the button. "You're
a very ugly button," she began. --Phil Janes, _The Galaxy Game_
My blog and resume: http://crow202.dyndns.org:8080/wordpress/
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
From: David Schwartz on 14 Jun 2008 19:42
On Jun 14, 10:25 am, Dances With Crows <danceswithcr...(a)usa.net>
wrote:

> tc qdisc add dev eth1 root tbf burst 20480 limit 20480 \
> mtu 1514 rate 32000bps

> ...as was mentioned in the Traffic Control HOWTO.  However, sustained
> transfer rates weren't 64K/sec, but were 15K/sec.  Doubling and
> quadrupling the numbers for rate, burst, and limit made no difference to
> the sustained transfer rates I observed.

It's hard to figure out what exactly happened. You claim you set a
traffic limit of 32,000 bits per second, and expected a transfer rate
of 64,000 somethings per second (bits? bytes?) but got 15,000. Why
would you expect 64,000 if you asked for 32,000? No conceivable bits/
bytes conversion can make that work.

What was the command you used? What was the rate you got (and specify
if it's in bits or bytes) and what did you expect? And how did you
measure it?

The problem may be that you are confusing bits with bytes. It also may
be that you are expecting *application* cooked data throughput to
equal raw network throughput.

It's hard to tell though because your command seems not to match any
expectation, with or without such errors.

DS
From: Dances With Crows on 14 Jun 2008 20:21
David Schwartz staggered into the Black Sun and said:
> Dances With Crows wrote:
>> tc qdisc add dev eth1 root tbf burst 20480 limit 20480 \
>> mtu 1514 rate 32000bps

>> ...as was mentioned in the Traffic Control HOWTO. However, sustained
>> transfer rates weren't 64K/sec, but were 15K/sec.
> It's hard to figure out what exactly happened. You claim you set a
> traffic limit of 32,000 bits per second, and expected a transfer rate
> of 64,000 somethings per second (bits? bytes?) but got 15,000.

That's 64K/sec (kilobytes) expected, got 15K/sec. (Actually I should
have expected 32K/sec, but 32 still != 15.)

> What was the command you used?

See first paragraph. That was the exact syntax given in the HOWTO for
limiting an interface to 256 kbit/second. All right, they might have
gotten their math wrong, but I usually expect HOWTOs to be reasonably
accurate. Please also note that removing the rule, then replacing it
with the numbers doubled, quadrupled or *ed by 8 for burst, limit, and
rate produced the same measured 15K/sec. I said that in the first
message, but it's worth repeating.

> And how did you measure it?

Sustained transfer rate using scp.

> It also may be that you are expecting *application* cooked data
> throughput to equal raw network throughput.

The overhead isn't *that* high with scp, and see above.

> It's hard to tell though because your command seems not to match any
> expectation, with or without such errors.

That's sort of why I posted here, since what I saw is so different from
what I expected. So: Who's using tc, how are you using it, and how
do you make it work the way you want it to?

--
That which does not kill us makes us stranger.
--Trevor Goodchild, Aeon Flux
My blog and resume: http://crow202.dyndns.org:8080/wordpress/
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
From: Andy Furniss on 14 Jun 2008 20:27
David Schwartz wrote:
> On Jun 14, 10:25 am, Dances With Crows <danceswithcr...(a)usa.net>
> wrote:
>
>> tc qdisc add dev eth1 root tbf burst 20480 limit 20480 \
>> mtu 1514 rate 32000bps
>
> It's hard to figure out what exactly happened. You claim you set a
> traffic limit of 32,000 bits per second, and expected a transfer rate
> of 64,000 somethings per second (bits? bytes?)

Just to make things even more confusing TC reads bps as bytes/sec you
have to use bit/kbit/mbit for bits/sec.

When using tc on gig nics you really need to turn off tcp segmentation
offload with IIRC ethtool -k. With it on you can get strange results.

When you put qdiscs on the root of eths you need to consider arp - these
will be delayed/dropped as well - which can mess things up.

Andy.
From: David Schwartz on 14 Jun 2008 22:52

One last clarification -- changing the configured 'tc' *rate* had no
effect on the transfer speed?!

DS
 |  Next  |  Last
Pages: 1 2
Prev: following wpa_supplicant negotiations.
Next: Unable to use stunnel with tin...