On Wed, 2012-12-05 at 12:33 -0800, Alex Burr wrote:
> > 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.

I ran the same test with more small packet sizes:
http://www.coverfire.com/archives/2012/12/05/per-packet-overhead-on-vdsl-3/

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.

Thanks