[LARTC] htb+sfq not being fair, while other methods have better results.

[LARTC] htb+sfq not being fair, while other methods have better results.

[Mike Mestnik]

[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

I'm running at 290Kbps and I have a cable modem(i'v gotten almost (1.54 * 3)Mbps down).

When I use htb3.6-020525 I get vary sparatic changes(in speed) on my 3 to 7 uploads.
With 7 uploads I should get about 4.5KBits/s, instead I get some much grater and some much less.
I'm using sfq perterb 10.
I'v got a complex setup (View Attachment).
The traffic going to handel 43 is what is not shapping correctly, with no other traffic.
When I tell the app (gtk-gnutella 3.x+my TOS patch) to shape the traffic it dose a better job(self
reporting).  Thats where I got the 4.5KBits/s mentioned above, all 7 uploads just solid at
4.xKBits/s
Also there is other data going through that qdisc, I don't see this being a problem thought.  See
I continually get SIN packets(all connections accepted but the app) then there is a read, if it
reads an HTTP header OR a gnutella header, it drops saying no open connection(In both cases the
connection get's dropped).
This data should be quite small and NEEDS to be ignored(as background noise), it should be
tolerable!

My first thought is that the drops on the backbone causes there to be A need for a burst of
bandwidth(for the retransmit), is this what the burst setting is for?
I get this idea from MRTG reporting a SOLID line at the htb shaped max.  While using the app I get
a wave form.

Please cc me in any reply.

Working Hard on this
Mike


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

[-- Attachment #2: qdisc.sh --]
[-- Type: application/x-sh, Size: 3324 bytes --]