On 31 Jul 2013, at 23:14, Sebastian Moeller <[email protected]> wrote:
> Hi Fred, > > thanks a lot. > > > On Jul 31, 2013, at 23:37 , Fred Stratton <[email protected]> wrote: > >> tc -s -d class show dev ge00 >> >> class htb 1:10 parent 1:1 leaf 110: prio 0 quantum 1500 rate 700000bit ceil >> 700000bit burst 1599b/1 mpu 0b overhead 0b cburst 1599b/1 mpu 0b overhead 0b >> level 0 >> Sent 15809014 bytes 115190 pkt (dropped 4733, overlimits 0 requeues 0) >> rate 3616bit 3pps backlog 0b 0p requeues 0 >> lended: 115190 borrowed: 0 giants: 0 >> tokens: 263560 ctokens: 263560 >> >> class htb 1:1 root rate 700000bit ceil 700000bit burst 1599b/1 mpu 0b >> overhead 0b cburst 1599b/1 mpu 0b overhead 0b level 7 >> Sent 15809014 bytes 115190 pkt (dropped 0, overlimits 0 requeues 0) >> rate 3616bit 3pps backlog 0b 0p requeues 0 >> lended: 0 borrowed: 0 giants: 0 >> tokens: 263560 ctokens: 263560 >> >> class fq_codel 110:1b8 parent 110: >> (dropped 0, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> deficit 84 count 0 lastcount 0 delay 10us >> >> >> >> tc -s -d class show dev ifb0 >> class htb 1:10 parent 1:1 leaf 110: prio 0 quantum 1500 rate 7000Kbit ceil >> 7000Kbit burst 1598b/1 mpu 0b overhead 0b cburst 1598b/1 mpu 0b overhead 0b >> level 0 >> Sent 192992612 bytes 168503 pkt (dropped 0, overlimits 0 requeues 0) >> rate 17096bit 4pps backlog 0b 0p requeues 0 >> lended: 168503 borrowed: 0 giants: 0 >> tokens: 27454 ctokens: 27454 >> >> class htb 1:1 root rate 7000Kbit ceil 7000Kbit burst 1598b/1 mpu 0b overhead >> 0b cburst 1598b/1 mpu 0b overhead 0b level 7 >> Sent 192992612 bytes 168503 pkt (dropped 0, overlimits 0 requeues 0) >> rate 17096bit 4pps backlog 0b 0p requeues 0 >> lended: 0 borrowed: 0 giants: 0 >> tokens: 27454 ctokens: 27454 >> >> class fq_codel 110:cc parent 110: >> (dropped 10, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> deficit -198 count 1 lastcount 1 ldelay 2.3ms >> class fq_codel 110:1d9 parent 110: >> (dropped 0, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> deficit 226 count 0 lastcount 0 ldelay 2us >> class fq_codel 110:1de parent 110: >> (dropped 0, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> deficit 238 count 0 lastcount 0 ldelay 10us >> class fq_codel 110:345 parent 110: >> (dropped 0, overlimits 0 requeues 0) >> backlog 0b 0p requeues 0 >> deficit 226 count 0 lastcount 0 delay 9us >> >> I changed the hard coded values in /usr/lib/aqm/functions.sh to arbitrary >> values, rebooted and obtained the same results. Both reflect the 7000kbit/s >> down and 700kbit/s up I entered in the window. > > What is the line rate as read out from the del modem or specified in > your contract? Speedtest.net shows the rate as circa 8.7 megabits/s down, 1 megabit/s up. Line has radio frequency interference from unidentified sources.. Target snr upped to 12 deciBel. Line can sustain 10 megabits/s with repeated loss of sync.at lower snr. Contract is for 'up to 20megabits/s'. 850 metres from exchange. Line length circa 1.2km. > >> I ticked the adsl box. Altering the value in functions.sh and unticking the >> box, with reboot, produced the same outcome. > > This nicely shows I screwed up my testing (and or forgot to reboot > between changes). Or I did try too high a data rate (initially 97% of the raw > link rate) > > >> >> >> >> traceroute google.com >> traceroute: Warning: google.com has multiple addresses; using 173.194.41.128 >> traceroute to google.com (173.194.41.128), 64 hops max, 52 byte packets >> 1 172.30.42.1 (172.30.42.1) 0.631 ms 0.323 ms 0.249 ms >> 2 * * * >> 3 10.1.3.234 (10.1.3.234) 22.596 ms 21.241 ms 22.392 ms >> 4 * 10.1.3.214 (10.1.3.214) 27.018 ms 26.703 ms >> 5 10.1.4.249 (10.1.4.249) 29.682 ms 28.923 ms 27.479 ms >> 6 * * * >> 7 * 209.85.252.186 (209.85.252.186) 30.379 ms * >> 8 72.14.238.55 (72.14.238.55) 25.745 ms 25.345 ms 25.594 ms >> 9 lhr08s03-in-f0.1e100.net (173.194.41.128) 27.566 ms 27.390 ms 27.663 ms >> >> mtr shows packet losses at hops 2-5 >> 10.1.3.* are Internet Watch Foundation. > > This looks pretty reasonable for an adsl link (could be way worse with > higher interleaving) > >> >> Netalyzr was used. I appreciate it is an imperfect metric. OK. Like the ping train idea. Cannot get netperf 2.6.0 to build on Ubuntu 12.04 > > Well, I ran into this issue before. In short netalyzr's worst case > delay numbers do not seem to reflect how an fq_codelled connection feels. > Netalyzr uses an unresponsive UDP probe to force the bottleneck router's > buffers to fill up; with unresponsiveness being a property no sane flow over > the intent should exhibit. Codel/fq_codel is tailored for responsive flows > and will only gradually increase its drop frequency so responsive TCP flows > will be controlled gently and keep link utilization high. Given enough time > codel will also rein in an unresponsive flows. But netalyzr's probe duration > is too short for that to be happening during netalyzr's runtime. > Fq_codel in my experience does a decent job at keeping interactivity high > even with competing traffic like netalyzr (so turn a ping train against say > 10.1.3.234 while netalyzr runs or try netperf-wrapper in addition). > So netalyzr really probes the worst case buffer depth against basically a > "denial of service" type of load; I am not fully sure what the expectancy on > the disc here should be. > > > best > Sebastian > > >> >> >> >> >> >> >> On 31 Jul 2013, at 21:38, Sebastian Moeller <[email protected]> wrote: >> >>> tc -s -d class show dev ge00 >> >> _______________________________________________ >> Cerowrt-devel mailing list >> [email protected] >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
