> From: Dan Siemon <[email protected]>
> 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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
