On Wed, Aug 21, 2019 at 12:51 AM Sebastian Gottschall
<[email protected]> wrote:
>
> >> i have seen this already. out plan here is that the user specifies the 
> >> internet connection type like vdsl2, cable, whatever in case of cake which 
> >> then will be used
> >> as argument
> >       Good goal, that also is theoretically well supported by cake with its 
> > multitude of encapsulation/overhead realated keywords. Unfortunately 
> > reality is not as nice and tidy as this collection of keywords implies, 
> > There are 8 keywords for ATM/AAL5 based encapsulations (ADSL, ADSL2, 
> > ADSL2+, ...), 2 for VDSL2, 1 for DOCSIS, 1 for ethernet, for a total of 12 
> > that all can be combined with one or more VLAN-tag keywords, for a total of 
> > 24 to 36 combinations. (And these are not even exhaustive, as e.g. the use 
> > of ds-lite can increase the per-packet overhead for IPv4 packets by another 
> > 20 bytes).
> >       Ideally one would just empirically measure the effective overhead and 
> > use the "overhead NN mpu NN" keywords instead, but that has issues as 
> > measuring overhead empirically is simply hard... The best bet would be to 
> > leverage BEREC to require ISPs to explicitly inform their customers of the 
> > effective gross-rates and applicable overheads for each link, but I am not 
> > holding my breath. Over at 
> > https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm we tried to 
> > give simplified instructions for setting the overheads for different access 
> > technologies, but these are not guaranteed to fit everybody (not even most 
> > users, as we have no numbers about the relative distributions of the 
> > different encapsulation options).
> >
> > Best Regards
> >       "another" Sebastian
>
> as i said. i just started. lets see if i can find a better solution or a
> clever way of auto detecting/measuring the overhead

+1. One of my favorite feynman sayings is "disregard" and we need new
thinking here.

I note that I maintain anywhere between 6-16 flent (netperf and irtt)
servers around the world,
and they are mostly underused....

Sometimes I've thought that a "right" approach would be to send a 10
sec full udp burst,
each packet pre-timestamped internally, at, say, 100Mbit...
and then measure "smoothness" at the receiver and ifconfig interface
(accounting for any other
traffic along the way).


>
> Sebastian
>
> >
> >
> >



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake

Reply via email to