(sent initially to incorrect address) Begin forwarded message: > From: Fred Stratton <[email protected]> > Subject: Re: [Cerowrt-devel] cerowrt-3.10.2-1 dev release + owamp > Date: 5 August 2013 11:45:33 BST > To: Sebastian Moeller <[email protected]> > > > On 5 Aug 2013, at 10:44, Sebastian Moeller <[email protected]> wrote: > >> Hi Fred, >> >> >> On Aug 4, 2013, at 15:03 , Fred Stratton <[email protected]> wrote: >> >>> >>> On 3 Aug 2013, at 21:53, Sebastian Moeller <[email protected]> wrote: >>> >>>> Hi Fread, >> >> Sorry for the typo... >> >>>> >>>> >>>> On Aug 3, 2013, at 12:36 , Fred Stratton <[email protected]> wrote: >>>> >>>>> I cannot currently access the gateway device. >>>>> >>>>> AFAIK, Cerowrt does not allow setting up a masquerade, and it is >>>>> physically difficult to access. I wish I could have a masquerade. The >>>>> device has a fixed IP address of 192.168.1.254. >>>> >>>> Interestingly, I can access my DSL-router on https://192.168.2.1 >>>> through cerowrt without any required configuration or firewall changes >>>> (and that also worked with 102.168.100.1 to the cable modem I used >>>> before). Have you recently tried this again? I do not run the required >>>> PPPOE client on cerowrt, but on the DSL-router. >>> >>> 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. > > 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. >> >> >>> >>> Openwrt has a masquerade function, which has been removed. There is no >>> doubt a good reason for this. >> >> Have you tried to assign an alias to the WAN interface in the same >> subnet as the modem's IP? Might do the trick… >> >>>> >>>>> >>>>> The target snr is set high, so the device does not retrain for months, so >>>>> the line speed remains constant. The ISP I use has been sold by >>>>> Telefonica to Sky, who use a fixed 7.5 target snr, so this stability may >>>>> go. I may change ISPs to overcome this. >>>>> >>>>> The device is a bridged 2wire 2700, which provides a frequency graph. >>>>> This looked normal. >>>>> >>>>> When I used a Broadcom based router, and TomatoUSB -shibby - I could >>>>> access the device and run RouterStats in a wine bottle. The interference >>>>> occurs at 0700 and 0200 every day. I have had the street lights serviced. >>>>> Chain saws are a problem. Aldi or Lidl sell cheap chain saws which are >>>>> not well suppressed electrically and cause random interference. >>>>> >>>>> I use a VDSL grade NTE >>>> >>>> Ah, in Germany XDSL capable modems (i.e. VDSL and ADSL) have a bad >>>> reputation for ADSL lines (think Jack of all trades, master of none) no >>>> idea whether that is deserved though… >>> >>> I am referring to the network termination wall plate, which contains rf >>> chokes which function like the coil craft device. >> >> Well, so do DSL modems, but not all chokes are of equal quality… that >> said I am quite impressed that you have common mode chokes in the >> termination equipment. In Germany all we get is a dumb frequency splitter, >> and with all IP telephony roll-out not even that anymore :) > > Te UK phone socket is mounted on a standard box that is used for electrical > sockets and switches in house walls. It has 2 halves - a backplate, installed > by the phone company and attached to the line, and a front plate, which the > end user can change. A number are available containing different chokes. > There is a phone socket - a UK phone socket, bigger than RJ-11, and an RJ-45 > socket for internet equipment. >> >>>> >>>>> , with large line chokes, shielded cables. and ferrite rings on the input >>>>> phone line. >>>> >>>> I guess this is for common mode rejection? When I had issues with a >>>> borderline del link in the past the coil craft TRF-r11 >>>> (http://www.coilcraft.com/pdf_viewer/showpdf.cfm?f=pdf_store:modjack.pdf) >>>> worked well for me. Then again ideally one would include the common mode >>>> chokes to all lines going into the modem (including ethernet and power). >>>> >>>>> All phones are DECT. >>>>> >>>>> The problem with a liberal Telecoms market is that there is only one >>>>> Wholesale provider, OpenReach. They will not investigate anything other >>>>> than voice line faults. The phone lines and cabinets are over 60 years >>>>> old. >>>> >>>> Well, sure but that is not going to change any time soon (as much as I >>>> think everybody should be connected by optic fiber). Admittedly I have >>>> soft spot in my heart for keeping infrastructure operating well past >>>> beyond its prime :) >>>> >>>>> >>>>> I am sure the 2700 is part of the problem. However other choices, like a >>>>> Thomson TG585v7, are associated with similar uplink delays. >>>> >>>> How do you measure the uplink delay? Oh I just remembered you had >>>> issues with getting netsurf 2.6 to work on ubuntu 12.4? Because Toke >>>> (https://github.com/tohojo/netperf-wrapper) has prepared nice packages of >>>> netsur-wrapper for ubuntu that include netsurf, so maybe you could try >>>> netsurf-wrapper to test your latencies. (One caveat, as Dave noticed in >>>> ubuntu 12.4 the saved plots from netsurf-wrapper suffer from a suboptimal >>>> python matplotlib) >>>> >>>>> and does not hold the line as well. despite its Broadcom SoC - the DSLAM >>>>> is an Ericsson, which returns BRCM. >>>>> >>>>> I mention all this on list not just to answer your question, but to >>>>> describe a fairly typical situation. The majority of users obtain >>>>> internet service over a land line., these days via ASDL2+. I have a >>>>> liberal telecoms market, can swap around the equipment II have attached >>>>> to a typical phone line perfectly legally to optimise the signal I >>>>> receive. Boxes like the 2wire and Thomson TG585v7 are what ISPs provide. >>>>> Cerowrt should at some point allow the ADSL user to surf the web and >>>>> download at the same time. >>>> >>>> I know that this is not going to help you, but my experience is that >>>> once I hooked up my cerowrt (wndr3700) to one of the internal ethernet >>>> ports of my ISP supplied (and remotely administered) >>>> DSL-router-modem-combo and switched all my machines to connect to cero >>>> networks, the internet got a whole lot more useable again immediately. >>>> Streaming and downloading and browsing the web got possible again once the >>>> ISP's router was relieved of being the bottleneck :) >>> >>> I have, in effect, done this. >> >> Ah, and that did not improve "interactivity"? That is a bit sad, and I >> would like to help, but it seems I am at the end of my wits. > > You have helped considerably, providing a data point of what does work. > > I may try different qdiscs with stab > > 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+ >> >> 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
