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

[Alex Burr <ajb44.geo@yahoo.com>]

> From: Dan Siemon <dan@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. 


Alex