[Codel] [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review
dan at coverfire.com
Wed Dec 5 23:12:49 EST 2012
On Wed, 2012-12-05 at 12:33 -0800, Alex Burr wrote:
> > 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.
I ran the same test with more small packet sizes:
This looks like it supports the PPS limit theory.
> 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.
That's disappointing news.
My VDSL2 modem (Alcatel Cellpipe 7130) shows:
Upstream line rate: 7344 kbps
Bearer Upstream payload rate: 6560 kbps
Can you shed some light on what causes the difference? Is it the 65/64
encoding and error correction overhead? I assume this does not take into
account things like the 802.3 header.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Codel