Re: [LARTC] patch: HTB update for ADSL users

[Ed Wildgoose <lists@wildgooses.com>]

>  After a bit of messing about -
> Patch would't apply and I couldn't see why. Then did it by hand and 
> had to move vars to top of function to get it to compile.


Hmm, perhaps it got corrupted because of the change in line endings when 
I pasted it in on a windows machine?  Piece of cake to apply manually.  
If I can get some PPoE settings then I will make a more generic patch 
and stick it on a website.

Can you paste the compile errors and tell me versions of gcc please?  I 
can't see any probs with that code though?  (They will be params passed 
in later anyway)

> I set my uprate to 280kbit in TC = 286720 bit/s I am synced at 288000 
> - as you probably are, in UK, on what BT call 250/500 and isps call 
> 256/512. I left a bit of slack just to let buffer empty if the odd 
> packet extra slips through. FWIW maxing downlink (576000 for me) will 
> probably mess up - you need to be slower or you don't get to build up 
> queues and will often be using your isp's buffer.
>
> I've been maxing uplink with bt for the last couple of hours and it's 
> working fine -


Yes, excellent isn't it!  I tested download rates (bearing in mind the 
difficulty of controlling those, and could get within a sliver of full 
bandwidth before the rate rises!

I see a two stage rise in ping times.  First it stays on 30ms, then it 
rises to 60ms-90ms, then it queues like crazy.  Interesting the kind of 
three step ramp up.  I have a hunch that packets don't arrive smoothly 
and queuing occurs at the ISP end (once we get near the limit) even 
though the average rate is below the max rate...?  (ie from time to time 
you start to see two packets ahead of you instead of just one)

> 100 packets transmitted, 100 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 15.586/44.518/67.984/13.367 ms
>
> It's just as it should be for my MTU.


Hmm, what's your MTU?  Those numbers look extremely low for 1500 byte 
packets (at least if you have a little downlink congestion as well?)

> When I get some time later I'll start hitting it with lots of small 
> packets aswell.


I have a 1meg downstream with 256 upstream, and I turned on bittorrent 
to try and flog the connection a bit.  Upstream was maxed out, but 
downstream was only half full.  However, ping times are 20-110.  I think 
they ought to be only 20-80 ish, and I'm trying to work out why there is 
some excess queuing (1500 ish mtu).  My QOS is based on the the 
(excellent) script from:
http://digriz.org.uk/jdg-qos-script/

Basically, HTB in both directions.  RED on the incoming stream (works 
nicely).  Outgoing classifies into 10 buckets, and ACK + ping are 
definitely going out ok in the top prio bucket, and the rest is going 
out in the prio 10 bucket....  But still these high pings...  Hmm


I would be interested to hear if anyone has a CBQ based setup and can 
tell me if that patch works for them?  Or even whether it works on the 
incoming policer properly?

It looks as though this is an adequate way to tackle the problem.  The 
alternative would be to hook into the enqueue side of the qdisk, 
calculate a new size value then and fix the code to refer to this value 
from then on.  It would be quite invasive though because it modifies 
kernel headers.  I would need someone who understands the scheduler in 
more detail to guide me as to whether it was neccessary

Ed W

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/