On 7 Aug 2013, at 14:38, Sebastian Moeller <[email protected]> wrote:

> Hi Fred,
> 
> this got a bit longish so I took the liberty to reduce the quoted text a bit
> 
> 
> On Aug 5, 2013, at 12:47 , Fred Stratton <[email protected]> wrote:
> 
> [snipp]
> 
>>>>> You are using 2 routers in series. I have disabled all routing functions 
>>>>> on the 2wire. It is transparent to the network.
>>>> 
>>>>    Which is exactly the situation I faced with the cable modem before; my 
>>>> cerowrt-router was provisioned with an IP address through the bridged 
>>>> cable-modem via DHCP, but I still could access the modem's 192.168.100.1 
>>>> with out any configuration required. I know there is some openwork 
>>>> information (http://wiki.openwrt.org/doc/howto/access.modem.through.nat) 
>>>> that makes it look like one needs to do more involved fiddling with the 
>>>> firewall, but that turned out not to be required with cerowrt. I do not 
>>>> know how that works if one runs a pppoe client on cerowrt though and I 
>>>> left cerowrt's ip address assignment in place. (My hunch is that since 
>>>> cerowrt leaves the typical 192.168.N.N ranges alone the whole issue gets 
>>>> reduced to a simple routing issue… and since Dave takes care that cero 
>>>> works well as secondary (test) router in a typical home situation, I guess 
>>>> routing 192.168.N.N is well with in cerowrt's scope)
>>>>    But, I guess you tried that already and it still does not work. Would 
>>>> be interesting to learn why…
>>> 
>>> The difference is that you have the ISP gateway as a primary device issuing 
>>> a DHCP address to the cerowrt secondary router. The 2 devices are then 
>>> obviously on the same ipv4 subnet.
>>> 
>>> I use the 2700 transparently. DHCP is turned off. If I turn it on, I have 
>>> to use the device in DMZ mode with its firewall on, which I do not want to 
>>> do.
> 
>       Sorry, to keep harping on this, but this is pretty close to what I did 
> with the cable modem. As I said I had it working with a similar setup as you 
> have, cerowrt was assigned a public IP (75.142.58.156) address by the 
> cable-ISPs dhcp server while the modems configuration interface was running 
> on the "private" 192.168.100.1. So the modem and cero were decidedly not on 
> the same IP subnet, but still I could connect to it without needing to change 
> anything. Initially, before I found out that it works out of the box I had 
> defined an alias IP address on the wan interface of (WAN2CABLEMODEM 
> ipv4-address:    192.168.100.2;  ipv4-netmask:   255.255.255.0). But it 
> turned out that this was not necessary as of cerowrt 3.3.8-17 I did not need 
> to do this any more, accessing the cable modem just worked by directing a 
> browser to 192.168.100.1.
> 
>       So, have you tried to access the modem recently by simply directing a 
> browser to its address? And have you tried the same after just configuring an 
> alias as hinted above? If so what was the result?
> 

I configured an alias using uci at your prompting. It works. I can now access 
the 2700.


>>> 
>>> Initially, I used the 2700 with the tomatoUSB router attached to that, and 
>>> then a router running openWRT. This setup allowed access to the 2700, 
>>> through a masquerade in tomatoUSB. 
>>> 
>>> Although ipv6 addresses were propagated throughout the network by Barrier 
>>> Breaker, ipv6 did not work, probably because of the way radvd works in 
>>> tomato.
>>> 
>>> I have never used the cerowrt as a secondary device because of this.
>>>> 
>>> 
> 
> [snipp]
> 
>>> I do not want to use cable, which is expensive. The DOCSIS box - a custom 
>>> Netgear device - has a poor reputation.
>>> 
>>> I do not want to use fibre, again, because when it comes here, it will be 
>>> supplied by BT/, and is traffic shaped and capped. The BT web site has 35 
>>> pages of price increases for this year.
>>> 
>>> I will continue with ADSL2+
> 
>       I fully agree that getting ADSL(2+) links debated and offering low 
> latency internet access is worthwhile as a considerable number of people 
> simply have no other choice available. And this is why your case is so 
> interesting! If you can improve the "interactivity" in your home and document 
> the required steps somewhere others will have an easier time.
> 
> Yes. Hopefully others using ADSL will also participate.
> 
> best
>       Sebastian
> 
> 
>>>> 
>>>> Best
>>>>    Sebastian
>>>> 
>>>> 
>>>>>> 
>>>>>> best regards
>>>>>>  Sebastian
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 3 Aug 2013, at 10:38, Sebastian Moeller <[email protected]> wrote:
>>>>>>> 
>>>>>>>> Hi Fred,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Aug 1, 2013, at 00:35 , Fred Stratton <[email protected]> wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 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..
>>>>>>>> 
>>>>>>>>        So it looks like specify a generous reserve for the shaper. Can 
>>>>>>>> you log into your modem and get the current line rates? The rf 
>>>>>>>> interference, is it constant (if you can get nice SNR per sub carrier 
>>>>>>>> or even ust bit loading per frequency plots) that is does it only 
>>>>>>>> affect the same frequencies or does it change? (I ask, because 
>>>>>>>> temporary interference might reduce the effective line rate, 
>>>>>>>> potentially moving the buffer back into the del modem)
>>>>>>>> 
>>>>>>>>> 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'.  
>>>>>>>> 
>>>>>>>>        So  ADSL2+ as you even mentioned it before.
>>>>>>>> 
>>>>>>>>> 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
>>>>>>>> 
>>>>>>>>        So I typically run a 1000 count ping against the nearest host 
>>>>>>>> that is on the other side of the DSL link that also gives consistent 
>>>>>>>> ping RTTs without load. Then I start my test loads like saturating the 
>>>>>>>> upload with a long runnig TCP transfer and opening 99 media heavy tabs 
>>>>>>>> in a browser (I really should try the chrome benchmark that Dave is 
>>>>>>>> using). And the I simply look through the ping statistic results, 
>>>>>>>> typically I look at the maximum, and at the standard deviation to get 
>>>>>>>> a handle on how tight the shaper held latency under control. (If I 
>>>>>>>> should get netperf-wrapper to work under Macosx I will try to use that 
>>>>>>>> for testing, but it does not even install, and if I get past that 
>>>>>>>> hurdle I will have to adjust for the differences between Gnu ping and 
>>>>>>>> BSD ping).
>>>>>>>> 
>>>>>>>> 
>>>>>>>>        Best Regards
>>>>>>>>                Sebastian
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>      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
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>> 
>>> 
>> 
>> _______________________________________________
>> 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

Reply via email to