Re: newbie: TC[NG] with (256kbit/s down and 768kbit/s up) on a router

Linux Advanced Routing and Traffic Control

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

 



Andreas Klauer wrote:
Am Wednesday 05 May 2004 10:34 schrieb Andy Furniss:

Andreas Klauer wrote:

Maybe my script will do: http://www.metamorpher.de/ipshape/


I renamed it to 'Fair NAT' and moved it to http://www.metamorpher.de/fairnat/, because there already was another script called ipshape. I didn't like the name anyway :-)


Nice script - one thing I found was that HTB dequeued packets in pairs -
with MTU 1500 and your 128kbit up this will hurt latency a bit.

The solution was to change from 1 to 0

#define HTB_HYSTERESIS 0 in net/sched/sch_htb.c


Thanks for the suggestion. I just recompiled the kernel - we'll see if I notice any change. However, I don't yet fully understand what HYSTERESIS actually does. There's a FAQ on docum.org, but I still don't get it.
What does 'packets in pairs' mean? Multiple packages at once sounds to me like burst.

YMMV of course - I have posted this here before.


I was using tcpdump a while back, to sus how (e)sfq worked. I had a very simple test setup, which just throttled bulk traffic to 51kbit my link is 256/512. I had burst set low and quantum to my MTU. Sniffing tcp after shaping I could see from the timestamps that the packets were being released in pairs - the rate was OK though. I changed timing from jiffies to cpu - no difference, I then remembered seeing the hysteresis page on stefs' site and tried that and it fixed it.

I saw an improvement in my latency when my upstream was full - doing the maths, it behaves as expected now, ie. the worst case delay is my baseline latency + bitrate for my speed/mtu.

If your real (ie. not a cable modem) upstream is 128k then a 1500 byte packet is going to take about 80-90ms - so in theory when your up is full you should be able to notice the difference in max reading on ping. It will pull avg down aswell.

There are reasons it may make no difference for you though -

Your setup shares all traffic per IP - so if others are using their uprate you will queue anyway, I only do bulk per IP so in theory my interactive packets never queue (the rate/burst for my interactive class is way higher than the traffic should ever be - easy on a home setup, probably not so easy in real world)

I use MTU/quantum 1478 - which may or may not have caused the pairing in the first place - I didn't test 1500.

I explicitly set low (c)bursts for bulk - I don't know what the defaults will be for you not setting them - but I guess they should soon get used up anyway.

Andy.



I wish they would make such things available in kernel configuration menu,
with a proper explanation. If you look in the code, there is loads of stuff that can be customized in the kernel by changing defines directly, but you rarely can change those things via kernel config. :-(


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



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

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