[Bloat] [Codel] [Cerowrt-devel] FQ_Codel lwn draft article review

Alex Burr ajb44.geo at yahoo.com
Wed Dec 5 12:33:44 PST 2012

> From: Dan Siemon <dan at coverfire.com>

> Thanks for the info. I guess I'll have to keep digging to figure out
> where the latency comes from.
> I did a couple more experiments which appear to confirm the large amount
> of per-packet overhead:
> http://www.coverfire.com/archives/2012/12/04/per-packet-overhead-on-vdsl2-2/

It almost looks like you're being limited to 5k packets/sec. Now, I know that some devices will only support a certain  packet rate, and it's not as stupid as it sounds because it's fairly rare to want to send max rate of solely minimum size packets. But I wouldn't expect it here, because I would expect a VDSL2 device to work with 100Mbps down, 50Mbps up, even if your contract and line only support much less. And the device would need to support more than 5k packets/sec to get 50Mbps, even at the biggest packet size. I guess you might be able to tell by plotting packet rate against packet size with more values of packet size: if it's a rate limit, there will be a sharp corner, whereas if it's overhead, there will should be more of a curve. The figure for the 75byte payload suggests a curve.

PTM-TC has a minimum overhead of 2 bytes/packet, IIRC. (I'm not counting the 65/64 cell overhead, because that is not (in a good implementation) aligned to packet boundaries and is therefore better thought of as a 1/65 tax on your line rate).  I'm not optimistic about tuning shapers based on these details, however, as unlike ATM/AAL5, implementations are allowed to insert any amount of padding between packets, so the per packet overhead is not predictable from the standard. There are also nonstandard framing implementations. 


More information about the Bloat mailing list