[Bloat] Stab overhead caliculation and mpu for ingress shaping.

[Y]

Hi Moeller , and all

I found this after I send mail :) then , about egress ,I got it :) 
https://www.spinics.net/lists/lartc/msg22399.html

and https://github.com/moeller0/ATM_overhead_detector shows 
stab mtu 2048 mpu 53 tsize 256

but I run this inside LAN on my pc,and now this situation is still
same.
then I set no mpu,now.

at last, for ingress like this,

$tc qdisc add dev $ext_ingress root handle 1: stab overhead -4
linklayer ethernet mpu 60 mtu 2048 tsize 256 hfsc default 13 


ingress shaping must think at table,  
whole speed =(5 per packets ) + (packet size + 10 overhead for PPPoA =
n*48). 

I have to measure it, more.

Thank you for reply , Moeller :)

Yuta.

2017-03-01 (水) の 22:36 +0100 に Sebastian Moeller さんは書きました:
> Hi Yuta,
> 
> > On Mar 1, 2017, at 19:37, Y <intruder_tkyf at yahoo.fr> wrote:
> > 
> > Hi , all.
> > 
> > I set root qdisc for traffic shaping like this
> > 
> > egress
> > $tc qdisc add dev $ext_ingress root handle 1: stab overhead -4
> > linklayer atm mpu 60 mtu 2048 tsize 256 hfsc default 13
> > 
> > ingress
> > $tc qdisc add dev $ext root handle 1: stab overhead -4 mpu 53
> > linklayer
> > atm mtu 2048 tsize 256 hfsc default 26
> > ($ works at script )
> > 
> > PPPoA WAN - modem/router - Ethernet LAN - My pc 1 interface.
> > 
> > engress overhead of PPPoA via ethernet is -4
> 
> 	So that indicates PPPoA VC/Mux, as encapsulation, correct? BUT
> that -4 assumes that the kernal already silently added 14 bytes to
> the packet size, which it does for ethernet interfaces. So is the
> traffic shaper running on the modem-router’s ATM interface directly
> or on your PC1? I typically would try to run https://github.com/moell
> er0/ATM_overhead_detector to empirically figure out the per packet
> overhead (but I note that this has never been tested with PPPoA data
> as far as I can remember)
> 
> > and mpu 53.
> 
> 	As far as I can tell with the linklayer ATM keyword the kernel
> will basically increase any runt packet to 53 automatically, so this
> seems redundant. (Linklayer atm will multiply the packet size by
> 53/48 and will also make packet size to be integer multiple of ATM
> cell size)
> 
> 
> > This is certain.
> > We can think without Ethernet padding at stab.
> 
> 	No, I disagree, _if_ the PPPoA packets exclude the padding we
> can ignore it but not otherwise… 
> 
> > 
> > My asking is whether that This is also correct at ingress shaping
> > or
> > not?
> > 
> > mpu for ingress in myscript = 60.
> > Because of minimal ethernet packet size = 60( with padding without
> > FCS)
> 
> 	I would assume this to be correct in your case
> 
> > 
> > oevrhead for ingress in myscript = -4.
> > Because I want to shape connection , so , must set speed setting *
> > 48 /
> > 53.
> 
> 	No, that is what linklayer atm does for you (and also the
> accounting for the required padding to always use an integer number
> of ATM cells per user packet).
> 
> Best Regards
> 
> > 
> > This is certain or not?
> > 
> > Yuta. 
> > 
> > For example. 
> > see this section (Extensive framing compensation (for
> > DSL/ATM/PPPoe))
> > https://www.bufferbloat.net/projects/codel/wiki/Cake/
> > _______________________________________________
> > Bloat mailing list
> > Bloat at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> 
>