I've been using the following modification to HTB for about 8 years now. Without it, shaping your very common PPPoE over ADSL link either wastes a lot of bandwidth (by shapping at 70% or less of the true ADSL speed) or cause queueing whenever there are a lot of small packets (by shaping at 80% of the true ADSL speed). With the following patch, as long as there aren't a lot of broadcasts leaking into your ADSL upstream, shaping becomes ultra precise: diff /usr/src/linux/net/sched/sch_htb.c sch_htb.c 590c590 < toks -= (long) qdisc_l2t(cl->rate, bytes); --- > toks -= (long) qdisc_l2t(cl->rate, ((bytes + 42 + 47) / 48) * 53); 603c603 < toks -= (long) qdisc_l2t(cl->ceil, bytes); --- > toks -= (long) qdisc_l2t(cl->ceil, ((bytes + 42 + 47) / 48) * 53); Of course this isn't a proper generic solution, as this will affect all instances of sch_htb on a given system. A proper solution would be having a flag that would use this formula on some htb scheduling and the default no formula on others. With the patch applied, just shape your pppX PPPoE interface at your actual physical ADSL upstream speed (I subtract 10kbps for network management). The explanation for the formula is: overheads added to a pure ppp packet are: 8 bytes pppoe header 14 bytes ethernet header 8 byte rfc1483 (for LLC/SNAP mode) 8 bytes for AAL5 trailer Total: 42 bytes after adding 42 bytes, every 48 byte unit becomes a 53 byte cell hence the (x + 42 + 47) / 48 * 53 Very few ADSL links might use VC instead of LLC encapsulation, that's 8 bytes less per packet. And so far all providers I use use LLC. If someone embarks on having this as an actual baseline kernel feature, I would suggest adding an integer field with the following values: 0 - No formula transformation 1 - The formula above 2 ... 7 - Room for extra formulas 8 and beyond - A simple linear overhead added to each packet, for instance 16 would add 16 bytes to each packet shaped. Regards, Marcelo Pacheco -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
