Re: Re: must cut the line down too much for shaping to work

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxxxxxxxxxxx>
To: lartc@xxxxxxxxxxxxxxx
Subject: Re:  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@xxxxxxxxxxxxxxx
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.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux