Hi Jonathan On Mar 29, 2015, at 08:17 , Jonathan Morton <chromati...@gmail.com> wrote:
> >> On 29 Mar, 2015, at 04:14, Sebastian Moeller <moell...@gmx.de> wrote: >> >> I do not think my measurements show that ingress handling via IFB is that >> costly (< 5% bandwidth), that avoiding it will help much. > >> Also the current diffserv implementation also costs around 5% bandwidth. > > That’s useful information. I may be able to calibrate that against similar > tests on other hardware. > > But presumably, if you remove the ingress shaping completely, it can then > handle full line rate downstream? What’s the comparable overhead figure for > that? Without further ado: moeller@happy-horse:~/CODE/CeroWrtScripts> ./betterspeedtest.sh -6 -H netperf-eu.bufferbloat.net -t 150 -p netperf-eu.bufferbloat.net -n 4 ; ./netperfrunner.sh -6 -H netperf-eu.bufferbloat.net -t 150 -p netperf-eu.bufferbloat.net -n 4 ; ./betterspeedtest.sh -4 -H netperf-eu.bufferbloat.net -t 150 -p netperf-eu.bufferbloat.net -n 4 ; ./netperfrunner.sh -4 -H netperf-eu.bufferbloat.net -t 150 -p netperf-eu.bufferbloat.net -n 4 2015-03-29 09:49:00 Testing against netperf-eu.bufferbloat.net (ipv6) with 4 simultaneous sessions while pinging netperf-eu.bufferbloat.net (150 seconds in each direction) ...................................................................................................................................................... Download: 91.68 Mbps Latency: (in msec, 150 pings, 0.00% packet loss) Min: 39.600 10pct: 44.300 Median: 52.800 Avg: 53.230 90pct: 60.400 Max: 98.700 ....................................................................................................................................................... Upload: 34.72 Mbps Latency: (in msec, 151 pings, 0.00% packet loss) Min: 39.400 10pct: 39.700 Median: 40.200 Avg: 44.311 90pct: 43.600 Max: 103.000 2015-03-29 09:54:01 Testing netperf-eu.bufferbloat.net (ipv6) with 4 streams down and up while pinging netperf-eu.bufferbloat.net. Takes about 150 seconds. Download: 91.03 Mbps Upload: 8.79 Mbps Latency: (in msec, 151 pings, 0.00% packet loss) Min: 40.200 10pct: 45.900 Median: 53.100 Avg: 53.019 90pct: 59.900 Max: 80.100 2015-03-29 09:56:32 Testing against netperf-eu.bufferbloat.net (ipv4) with 4 simultaneous sessions while pinging netperf-eu.bufferbloat.net (150 seconds in each direction) ...................................................................................................................................................... Download: 93.48 Mbps Latency: (in msec, 150 pings, 0.00% packet loss) Min: 51.900 10pct: 56.600 Median: 60.800 Avg: 62.473 90pct: 69.800 Max: 87.900 ....................................................................................................................................................... Upload: 35.23 Mbps Latency: (in msec, 151 pings, 0.00% packet loss) Min: 51.900 10pct: 52.200 Median: 52.600 Avg: 65.873 90pct: 108.000 Max: 116.000 2015-03-29 10:01:33 Testing netperf-eu.bufferbloat.net (ipv4) with 4 streams down and up while pinging netperf-eu.bufferbloat.net. Takes about 150 seconds. Download: 93.2 Mbps Upload: 5.69 Mbps Latency: (in msec, 152 pings, 0.00% packet loss) Min: 51.900 10pct: 56.100 Median: 60.400 Avg: 61.568 90pct: 67.200 Max: 93.100 Note that I shaped the connection at upstream 95p%: 35844 of 37730 Kbps and downstream at 90%: 98407 of 109341 Kbps; the line has 16bytes per packet overlay and uses pppoe so the MTU is 2492 and the packet size itself is 1500 + 14 + 16 = 1530 (I am also not sure whether the 4 byte ethernet frame check sequence is transmitted and needs accounting for, so I just left it out), so with TCP over IPv4 adding 40 bytes overhead, and TCP over IPv6 adding 60 bytes. So without SQM I expect: IPv6: Upstream: (((1500 - 8 - 40 -20) * 8) * (37730 * 1000) / ((1500 + 14 + 16) * 8)) / 1000 = 35313.3 Kbps; measured: 35.23 Mbps Downstream: (((1500 - 8 - 40 -20) * 8) * (109341 * 1000) / ((1500 + 14 + 16) * 8)) / 1000 = 102337.5 Kbps; measured: 91.68 Mbps (but this is known to be too optimistic, as DTAG currently subtracts ~7% for G.INP error correction at the BRAS level) IPv4: Upstream: (((1500 - 8 - 20 -20) * 8) * (37730 * 1000) / ((1500 + 14 + 16) * 8)) / 1000 = 35806.5 Kbps; measured: 35.23 Mbps Downstream: (((1500 - 8 - 20 -20) * 8) * (109341 * 1000) / ((1500 + 14 + 16) * 8)) / 1000 = 103766.8 Kbps; measured: 91.68 (but this is known to be too optimistic, as DTAG currently subtracts ~7% for G.INP error correction at the BRAS level) So the upstream throughput comes pretty close, but downstream is off, but do to the unknown G.INP “reservation”/BRAS throttle I do not have a good expectation what this value should be. And with SQM I expect: IPv6 (simplest.qos): Upstream: (((1500 - 8 - 40 -20) * 8) * (35844 * 1000) / ((1500 + 14 + 16) * 8)) / 1000 = 33548.1 Kbps; measured: 32.73 Mbps (dual egress); 32.86 Mbps (IFB ingress) Downstream: (((1500 - 8 - 40 -20) * 8) * (98407 * 1000) / ((1500 + 14 + 16) * 8)) / 1000 = 92103.8 Kbps; measured: 85.35 Mbps (dual egress); 82.76 Mbps (IFB ingress) IPv4 (simplest.qos): Upstream: (((1500 - 8 - 20 -20) * 8) * (35844 * 1000) / ((1500 + 14 + 16) * 8)) / 1000 = 34016.7 Kbps; measured: 33.45 Mbps (dual egress); 33.45 Mbps (IFB ingress) Downstream: (((1500 - 8 - 20 -20) * 8) * (98407 * 1000) / ((1500 + 14 + 16) * 8)) / 1000 = 93390.2 Kbps; measured: 86.52 Mbps (dual egress); 84.06 Mbps (IFB ingress) So with our shaper, we stay a bit short of the theoretical values, but the link was not totally quiet so I expect some loads compared o the theoretical values. > You see, if we were to use a policer instead of ingress shaping, we’d not > only be getting IFB and ingress Diffserv mangling out of the way, but HTB as > well. But we still would run HTB for egress I assume, and the current results with policers Dave hinted at do not seem like good candidates for replacing shaping… Best Regards Sebastian > > - Jonathan Morton > _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel