[LARTC] HTB MPU

[Jason Boxman]

On Friday 14 May 2004 03:05, Ed Wildgoose wrote:
<snip>
> I appears that you could change the patch in tc/core in fn
> tc_calc_rtable, from:
>
>   + if (overhead)
>   +     sz += overhead;
>
> to something like:
>
>   + if (overhead)
>   +     sz += (((sz-1)/mpu)+1) * overhead;

I did that and recompiled iproute2.  I kicked my rate up to my actual 
connection, 256Kbps, and I was nailed as usual.  No measurable change using 
the above with an mpu of 54 for each class.  Nothing changed at my 
handicapped rate of 160kbit either.

tc qdisc add dev eth0 root handle 1: htb default 90
tc class add dev eth0 parent 1: classid 1:1 htb rate 160kbit ceil 160kbit \
  mpu 54
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 64kbit ceil 64kbit \
  mpu 54 prio 0
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 80kbit ceil 160kbit \
  mpu 54 prio 1
tc class add dev eth0 parent 1:1 classid 1:50 htb rate 8kbit ceil 160kbit \
  mpu 54 prio 1
tc class add dev eth0 parent 1:1 classid 1:90 htb rate 8kbit ceil 160kbit \
  mpu 54 prio 1

<snip>
> Can someone with a working setup try this out and see if it helps?

No joy.  I had more success modifying the HTB_HYSTERESIS compile time option.

What would be nice is something that would calculate the actual PPPo(E|A) 
overhead on the fly at runtime and schedule accordingly.

Afterall, this whole [your rate] * 0.8/.75/.65 (I'm stuck with the latter 
value) is kind of a hack.  If a scheduler existed that understood the packets 
were ATM'd and the overhead imposed therein, you could simply specify your 
rate as what it really is.  By using a fraction of your actual egress 
bandwidth you're configuring for the worst case scenario.  In reality, 
depending on your traffic I think you can approach your actual rate more 
closely.

(The classical example being sending an unloaded TCP ACK costing your two ATM 
cells and essentially wasting an entire ATM cell.  But in some situations 
your traffic might be mostly large IP packets and then your waste overhead is 
greatly reduced...)

Anyway, is there any known work on such a scheduler?  I'd be interested in 
beta testing anything under development.

> Ed W
>