Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections

[Andy Furniss <adf.lists@gmail.com>]

Sebastian Moeller wrote:

> Thanks for sharing your test case; I can repeat these results
> exactly on my machines (I also tried htb instead hfsc for fun: same
> result as to be expected see below). Looking back at
> http://lxr.free-electrons.com/ident?i=qdisc_pkt_len_init (line
> 2731):
>
> qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len ;
>
> I begin to realize this function is not responsible for adding
> single wire packet’s ethernet header, but for figuring out in how
> many on-the-wire packets to chop down a GSO packet , and add the
> header overhead for the additional wire packets, I had completely
> looked over the (gso-segs - 1) part, oops.

Glad it helped - I know from trying, and giving up, how hard/error prone
reading kernel code can be :-)

>
> @cerowrt-devel: everyone using link layer ATM you might want to try
> to reduce the the per packet overhead by 14… (but please test)

Maybe you mean overhead calculated by a script?

Just to be clear, I expect that wrt would be shaping on ppp, so you
don't need to take 14 if that's the case.


> So I stand corrected, you are right, tic’s stab automatically adds
> the ethernet header. So I am off to repeat my netperf-wrapper tests
> right now again with overhead of 30 instead of 44, again these tests
> confirm your observation. Interestingly, it seems netperf-wrapper’s
> RRUL test really is suited to figure out the overhead: while shaping
> to 100% of line rate (on ADSL2+ where line rate rate is the net line
> rate (after FEC)) specifying too small an overhead the ICMP latency
> plot shows larger deviations from the expected unload RTT plus 10ms.
> Too large an overhead however just decreases the good put bait while
> leaving the latency well under control.

I wouldn't word it like "stab adds ..." This is nothing to do with stab
really - just the only length stab knows is skb->len and that means
different things on different interfaces because of how the kernel works.

(I haven't retested all this, but I doubt it's changed)

On ppp skb->len = ip len

On eth skb->len = ip len + 14

On vlan skb->len = ip len + 18

If you ran my script on various interfaces without stab I expect you
would still be able to see the difference - everyone who does any tc on
eth gets shaping with ip+14 sized packets.

Even without tc involved I think you could see the difference looking at
ip -s ls xxxx type stats on different interfaces.