On 3 Aug 2013, at 21:53, Sebastian Moeller <[email protected]> wrote: > Hi Fread, > > > 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. Openwrt has a masquerade function, which has been removed. There is no doubt a good reason for this. > >> >> 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. > >> , 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. > > 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
