LARTC - Nov 2005 - must cut the line down too much for shaping to work

Hi, my situation: One internet connection 256 kbps uplink/downlink,
pretty stable speed, a Linux router with three NICs (one to ISP, one to
DMZ and one with VLANs enabled to our LAN). Each of three VLANs (1, 10,
11) is a region for me; id 1 gets guaranteed 128 kbps, id 10 and 11 both
get guaranteed 64 kbps (both uplink and downlink).

Simple configuration. After I read relevant parts of lartc (GREAT
READING by the way, thanks!) and dozen other docs I was able to set this
thing up: I mark packets in the iptables mangle FORWARD chain according
to from where the packet comes and where it wants to go. It does work,
but...

On many places there is a warning that the shaping box must stay a
bottleneck of the route so the queue can start to fill inside it and be
shaped. Somethere they say a few percent of the upstream rate must be
sacrificed, some say 25%...

Okay, I tried to set a full 256kbit on a root HTB class, just for fun.
No shaping. I set 230kbit then. Still nothing. The beast started to work
as expected when I cut my line to 220 kb/s! It means effectively fall of
the download speed from some 29-30 KB/s to about 26 KB/s as I measured it.

I consider it to be serious, given our internet connection is VERY
expensive (because of the unfortunate location of the company building,
but we are working on the cost problem). I do not know whether I can
afford such resource loss presently...

Is it possible I got something not tuned well or is fall from 256 to 220
kb/s normal for usual shaping?

Thanks in advance.

-- 
\//\/\
(Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.)

One more to my previous posting:

What I want to get is to not let any of the three regions to dominate
the line and to maintain the 128-64-64 bandwidth ratio. I''m not
concerned in the ceil (limit the region''s upload/download when the line
is free), I wish free borrowing.

Isn''t there any other method instead of HTB, not suffering with the 15%
bandwidth loss, that would be capable of bringing me what I want?

Thanks,

VM

i''m only sacrificing 4kbit on my 512kbit uplink and i''m
getting the results
I want. Can you be more specific as to how it was "failing" when you
had it
set closer to the actual link speed?

The reason to keep the speed limit under the actual connection is more of a
latency issue. The reason to do it is so you keep the queue on your server
and thus can guarentee lower latency for certain things. From the sound of
youe setup, a 2:1:1 ratio split, the latency thing isn''t really an
issue at
all. I don''t see why you couldn''t just keep it as the actual
connection
bandwidth.

Please say what didn''t work instead of just saying
"didn''t work as expected"
or "No shaping." Give some detailed output that you''re basing
this statement
on.

My best suggestion on the limited information would be to mabye set it up
with a root class of 256kbit, then setup the child classes as 120-60-60 with
borrowing. In my own usage, leaving some free bandwidth that every subclass
has to borrow from seems to work better than assigning it all.

Also, are you basing the drop from 30KB/s to 26KB/s off measured transfers
or just calculating the bandwidth. If you haven''t tested your actual
bandwidth without HTB active I''d suggest doing that.

- Jody Shumaker

On 11/2/05, Vlada Macek <tuttle@bbs.cvut.cz>
wrote:
>
> One more to my previous posting:
>
> What I want to get is to not let any of the three regions to dominate
> the line and to maintain the 128-64-64 bandwidth ratio. I''m not
> concerned in the ceil (limit the region''s upload/download when the
line
> is free), I wish free borrowing.
>
> Isn''t there any other method instead of HTB, not suffering with
the 15%
> bandwidth loss, that would be capable of bringing me what I want?
>
> Thanks,
>
> VM
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[At 02.11.2005 20:38, Jody Shumaker kindly sent the following quotation.]
> i''m only sacrificing 4kbit on my 512kbit uplink and i''m
getting the
> results I want. Can you be more specific as to how it was
> "failing" when you had it set closer to the actual link speed?
Sure, I just tried to keep the message as short as possible, expecting
that it will be clear what I was talking about. Sorry.
> The reason to keep the speed limit under the actual connection is
> more of a latency issue. The reason to do it is so you keep the
> queue on your server and thus can guarentee lower latency for
> certain things. From the sound of youe setup, a 2:1:1 ratio split,
> the latency thing isn''t really an issue at all. I don''t
see why
> you couldn''t just keep it as the actual connection bandwidth.
>
> Please say what didn''t work instead of just saying
"didn''t work as
> expected" or "No shaping." Give some detailed output that
you''re
> basing this statement on.
Ok, I''ll describe the testcase. All measures was not a matter of
seconds, I always waited at least for a 30 seconds when the situation
stabilized.

I worked with three xterms, each in one of the region, each wgeting a
big file from differrent quick internet server. One station without
HTB on the router got the data as quick as 29-30 KB/s (real and pretty
stable speed). I take this as a 100% bandwidth.

Still without HTB, I started all three wgets and they fairly shared
the 100% bandwidth. But I said I wish 2:1:1 ratio (128-64-64 ideally)
and this was not reached with HTB''s 256 kbit ceil - the bandwidth was
still shared 1:1:1. I concluded that the shaping do not work and one
line could therefore dominate the line, keeping down the others when
the line is stressed.

Some 2:1:1 results came when I set ceil down to about 220-225kbit.
Then the first line''s wget was truly getting data twice as quick as
the other ones. This agreed with the statements in articles that I
always need to give away some precious bandwidth to be able to shape
it. And with this setting, even one wget gets the data at about 26
KB/s rate, which is a pretty big loss from out point of view (big real
bandwidth cost from the ISP).

So, my shaping works, but the cost is big. I was asking here whether
this cost is normal or I could have something untuned in the setup.
> My best suggestion on the limited information would be to mabye set
> it up with a root class of 256kbit, then setup the child classes
> as 120-60-60 with borrowing. In my own usage, leaving some free
> bandwidth that every subclass has to borrow from seems to work
> better than assigning it all.

I''ll try it, when we turn the shaping on, even when I doubt it will
work. But I do not know about it much, we''ll see.

==
One more question in case someone here knows, sorry about
overweighting the message: The reason we had to turn the shaping off
temporarily was that we experienced a blackout and our D-Link
DGS-1248T switch forgot all its settings (namely VLANs) without power.
We are currently not able to find out whether it''s usual (and how to
defend) or we got a defective piece. If you have a clue, please drop
me a note.

Thanks in advance!

- --

\//\/\
(Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDaxZ211BCQx8FlCQRAkRQAKCTPnfRggv1TwVzUKXIr3fHoBkV/ACgnB39
wu+abfujhVSPmhykW15cOos=iiS9
-----END PGP SIGNATURE-----

I am using a netbsd machine to shape as 768k dsl for voip+ traditional 
uses. I have been using HFSC queuing quite
effectively for some months. I too have had to cap the pipe at 740 kbps. 
Part of this is the aforemention need for lowest
latency possible, but one also looses overhead to framing, in the case of 
IP over 802.3 there are at least 38 if not 42
bytes out of every 1500 (assuming you are using the MTU of 1500, the 
largest mtu allowed on 802.3) Then your may not have a
512kb uplink of ether, you might have 512kb of ATM bandwidth which is 
another set of framing overhead. Normaly one can
expect to loose a few % here as well.

For best results, defragment everything going in or out, use TCP SYN/ACK 
compression.

And yes using IP6 is an advantage as the IP headers are smaller.

In short, if you are finding discrepancies in usable vs paid-paid for 
bandwidth, look too the frames. If you are still
having problems, test the line. Rarely is the problem with the 
cpu/ram/NIC, not being responsive enought.  Sometimes the
speed regulation isnt quite what the ATM bridge is expecting and you can 
loose packets on the bridge if they dont get cached
well enough.

Using a high quality onboard ISDN or Frame Driver can avert these problems 
i am told. But I am happy to have 740k our of
768k knowing that the boss''s telephone wont splutter.



On Fri, 4 Nov 2005, Vlada Macek wrote:
> Date: Fri, 04 Nov 2005 09:06:20 +0100
> From: Vlada Macek <tuttle@bbs.fsik.cvut.cz>
> To: lartc@mailman.ds9a.nl
> Subject: Re: [LARTC] Re: must cut the line down too much for shaping to
work
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [At 02.11.2005 20:38, Jody Shumaker kindly sent the following quotation.]
>
>> i''m only sacrificing 4kbit on my 512kbit uplink and
i''m getting the
>> results I want. Can you be more specific as to how it was
>> "failing" when you had it set closer to the actual link
speed?
>
> Sure, I just tried to keep the message as short as possible, expecting
> that it will be clear what I was talking about. Sorry.
>
>> The reason to keep the speed limit under the actual connection is
>> more of a latency issue. The reason to do it is so you keep the
>> queue on your server and thus can guarentee lower latency for
>> certain things. From the sound of youe setup, a 2:1:1 ratio split,
>> the latency thing isn''t really an issue at all. I
don''t see why
>> you couldn''t just keep it as the actual connection bandwidth.
>>
>> Please say what didn''t work instead of just saying
"didn''t work as
>> expected" or "No shaping." Give some detailed output
that you''re
>> basing this statement on.
>
> Ok, I''ll describe the testcase. All measures was not a matter of
> seconds, I always waited at least for a 30 seconds when the situation
> stabilized.
>
> I worked with three xterms, each in one of the region, each wgeting a
> big file from differrent quick internet server. One station without
> HTB on the router got the data as quick as 29-30 KB/s (real and pretty
> stable speed). I take this as a 100% bandwidth.
>
> Still without HTB, I started all three wgets and they fairly shared
> the 100% bandwidth. But I said I wish 2:1:1 ratio (128-64-64 ideally)
> and this was not reached with HTB''s 256 kbit ceil - the bandwidth
was
> still shared 1:1:1. I concluded that the shaping do not work and one
> line could therefore dominate the line, keeping down the others when
> the line is stressed.
>
> Some 2:1:1 results came when I set ceil down to about 220-225kbit.
> Then the first line''s wget was truly getting data twice as quick
as
> the other ones. This agreed with the statements in articles that I
> always need to give away some precious bandwidth to be able to shape
> it. And with this setting, even one wget gets the data at about 26
> KB/s rate, which is a pretty big loss from out point of view (big real
> bandwidth cost from the ISP).
>
> So, my shaping works, but the cost is big. I was asking here whether
> this cost is normal or I could have something untuned in the setup.
>
>> My best suggestion on the limited information would be to mabye set
>> it up with a root class of 256kbit, then setup the child classes
>> as 120-60-60 with borrowing. In my own usage, leaving some free
>> bandwidth that every subclass has to borrow from seems to work
>> better than assigning it all.
>
>
> I''ll try it, when we turn the shaping on, even when I doubt it
will
> work. But I do not know about it much, we''ll see.
>
> ==>
> One more question in case someone here knows, sorry about
> overweighting the message: The reason we had to turn the shaping off
> temporarily was that we experienced a blackout and our D-Link
> DGS-1248T switch forgot all its settings (namely VLANs) without power.
> We are currently not able to find out whether it''s usual (and how
to
> defend) or we got a defective piece. If you have a clue, please drop
> me a note.
>
> Thanks in advance!
>
> - --
>
> \//\/\
> (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDaxZ211BCQx8FlCQRAkRQAKCTPnfRggv1TwVzUKXIr3fHoBkV/ACgnB39
> wu+abfujhVSPmhykW15cOos> =iiS9
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
  Microsoft: Where do you want to go tomorrow?
  Linux: Where do you want to go today?
  BSD: Are you guys coming, or what?


Robin-David Hammond	KB3IEN
 	www.aresnyc.org.