From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 064A021F1B9 for ; Thu, 20 Feb 2014 12:43:22 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D7CF420CB3; Thu, 20 Feb 2014 15:43:20 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 20 Feb 2014 15:43:20 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imap.cc; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=EeNmKFOHAhFr2x2vHdX0LfL9w8k=; b=IEyUwgPemcAfW+AUhBLOjCN7YVFv 3MhfTeqUismoFrqGr8Qg3JwbuUwYKBPBeLYd7uOxCxE2HudWCjO3ExDApbKooX1o DM0xFpSQ7dmkp3FYf/vnAOB/PxJ8qGhz/8k4cnCh0kOT5SBrHOvUUy9dlOT3zKxb lEk7NSK+ZRuVE3w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=EeNmKFOHAhFr2x2vHdX0Lf L9w8k=; b=EAWYXoU9pLT5uOWUBKU5oxsAL+rGj4WcXGOUMgRmuESlGBItz/oMDh tW1PluFmmATXjLnwCSiJIKwGAT38g+bh2nprfRyMa+d/h1QwqM7KrL3xXSUpsO6D Csq/KCt6ArDrq6J6yqhJze3Z26u8G8fWFS+wS1TGedA2EoneEY53E= X-Sasl-enc: 1d+5CKoi6MfLKN6irqFs1Prl3t2ajOMfYbClH303HvoG 1392929000 Received: from [172.30.42.8] (unknown [78.145.42.63]) by mail.messagingengine.com (Postfix) with ESMTPA id E2BCBC00005; Thu, 20 Feb 2014 15:43:19 -0500 (EST) Message-ID: <530668A4.4040604@imap.cc> Date: Thu, 20 Feb 2014 20:42:12 +0000 From: Fred Stratton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sebastian Moeller , cerowrt-devel@lists.bufferbloat.net References: <53059269.1000300@imap.cc> <5305E875.9070508@imap.cc> <5305E893.8020604@imap.cc> <5306099C.1090604@xyz.am> <530609BE.6030508@imap.cc> <5FCE9372-5DCD-4CDD-885C-706B5A7F19A2@gmx.de> <53063A54.9050102@imap.cc> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] just when I thought it was safe to do a release X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:43:23 -0000 ADSL2+ is better than ADSL in this context, as you point out. I thought=20 it was worth trying for a week or two, rather than relying solely on the = literature. The combined VDSL2/ADSL2+ approach is interesting. It is unlikely to=20 happen here,as BT has an effective monopoly of fibre since its=20 publicly-owned competitor went bankrupt. You must be using Annex M, which here is now mainly for business use, at = extra cost. OpenWRT test builds require an older version of uboot than the one=20 TP-Link uses. There is no easy regression path,and the builds are=20 immature. They will never allow a choice between ADSL,ADSL2, AND ADSL2+. Although blogic is principal developer in Berlin, the majority of work=20 has been done in Polen. Ich kann Deutsch verstehen, (the British Royal Family is more German=20 than a BMW) but I find Polish far more difficult. On 20/02/14 20:08, Sebastian Moeller wrote: > Hi Fred, > > On Feb 20, 2014, at 18:24 , Fred Stratton wrote:= > >> Aha.. beyond the DSLAM... >> >> I was unaware of that BRAS PPPoE issue. > And there is no good reason to be aware of that particular screw-up :)= > >> Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipset. = The manufacturers firmware allows you to choose ADSL2+, or ADSL2, or ADSL= , specifically. > My observation in the past was that the DSLAM has to play along; if yo= u try ADSL2 on a ADSL1 line card it will just not sync. Now the ISPs are = free to expose several modes on the same line card if they want to. At le= ast in Germany the trend seems to be combined VDSL2/ADSL2+ line cards (wi= th ADSL2+ as fall back for long distances and customers with old modems) > >> As you would expect ADSL had the least problems, and gave a full 8 meg= abits/s. > I could easily be off, but from looking at the standards I would have = guessed that ADSL2+ would be more resilient against interference (at the = same bandwidth as ADSL1 it should be more robust, but I assume most modem= s will trade this additional robustness for higher sync) > >> The 2Wire has far fewer problems with the frequent lease renewals the = ISP imposes. The TD-W8970 has odd problems. > Did you use openwrt on the TD-W8970 rot stock firmware? > >> You are correct. Most of the telephone cable is shared to the exchange= =2E Most properties have a 10-pair cable, where only one pair is used. Bi= t-swapping is supposed to mitigate against crosstalk. > Yes, but I can only do so much, vectoring will help a lot in that rega= rd (by measuring the cross-talk and shaping all signals so that the look = great after experiencing cross-talk; pretty cool technology, but also a c= omputational expensive way to push the inevitable fiber-to-the-home furth= er into the future). > >> Even when FTTC appears, all cables will be adjacent up to the local MS= AN. > This is why vectoring, with its promise to eradicate DSLAM NEXT and li= ne FEXT almost completely, is going to help a lot. Since fiber is not an = option, I am looking forward to switching to that, 100Mbit in 40 Mbit out= also is a much saner asymmetry than my current 16in 2.5 out (which is ac= tually quite reasonable for ADSL2+ ;) ) > >> I doubt I shall go that route. I have cable outside the front door alr= eady, which nobody uses, as they are still trying to recoup their infrast= ructure costs - approx 1.5 milliard euro. All the pit covers say 'NYNEX' = on them. > Well, in germany cable download looks quite nice but the upload with 5= M max (2-4 typical) is not quite as good as current VDSL offers (10up) an= d definitely way off the promised 40up; also a cable node in germany shar= es ~400MBit among its users while VDSL typical shares 1Gbit. > > best regards > Sebastian > >> To get back on-topic, I accept that it is unlikely that cero has affec= ted the situation. >> >> >> >> On 20/02/14 14:38, Sebastian Moeller wrote: >>> Hi Fred, >>> >>> On Feb 20, 2014, at 14:57 , Fred Stratton wrot= e: >>> >>>> On 20/02/14 13:56, Fred Stratton wrote: >>>>> The DSLAM at the exchange is an Infineon, Germany's finest. >>> The issue I mentioned did not happen at the DSLAM so sync was not af= fected, but at the PPPoE termination point, the BRAS, which accidentally = throttles a number of users below their rated bandwidths, rather obscure = and since restricted to ADSL1 hopefully a legacy issue that will go away = at latest once all ADSL1 line cards are retired... >>> >>>>> I am using a 2Wire 2700 as the bridged connection device. The highe= r frequency bins, as graphed, as not optimally used. The device uses ADSL= 2+. The user cannot change this mode. >>>>> >>>>> The 2Wire is very effective at suppressing impulse noise. >>>>> >>>>> The line is uncapped, with unlimited downloads. >>> Just as I remembered, that means that syncing at good line moments j= ust does not leave enough slack-bits for worse-case scenarios, hence your= approach to increase the line tolerance by increasing SNRM to be better = equipped for your sync to survive the interference episodes=85 It is a pi= ty that one can not really request the modem to only sync at a specific b= andwidth directly. >>> >>>>> The RF Interference source is unknown. Possible culprits are >>>>> >>>>> analogue to digital set top TV conversion boxes. >>>>> passing vehicles. >>>>> holes in the ionosphere. >>>>> >>>>> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html >>>>> >>>>> I can find no PPPoE errors. >>> Then I think that cerowrt should have no effect on the wan speed. >>> >>>>> The neighbours, based on their SSIDs, are always changing ISPs, and= so are not a constant source of RF interference in that sense. >>> Well, evenif everybody uses BT's infrastructure there still can be s= ome shared cable segments which can cause cross-talk. So even a local loo= p unbundled ISP that runs its own DSLAM-lincards at the central office wi= ll have some of its wire share a bundle with other ISP's wire along the l= ines to the Serving area interface, and that is sufficient for degradatio= n of your line capacity. Only if your neighbors and you directly connect = to two different outdoor slams/msans you would be not affected by their d= el usage. And if you suspect that they cause true RF interference, that c= an come easily in via the power lines=85 Since we humans have no good sen= se for electrical fields locating the source of RF interferes is a black = art=85 >>> >>> Best Regards >>> Sebastian >>> >>>>> On 20/02/14 13:15, Sebastian Moeller wrote: >>>>>> Hi Fred, >>>>>> >>>>>> >>>>>> On Feb 20, 2014, at 12:35 , Fred Stratton w= rote: >>>>>> >>>>>>> On 20/02/14 11:35, Fred Stratton wrote: >>>>>>>> I am aware of the DSLStats executable produced by Bald_Eagle on = Kitz. >>>>>>>> >>>>>>>> This was designed primarily with the Huawei HG 612 in mind, for = VDSL2 connection monitoring. >>>>>>>> >>>>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently = available, with the password 'admin', a feature I do not like, even on a = bridged device. >>>>>> Ah, that sounds not very safe (would it hurt the manufacturers= to switch to ssh on those devices and allow users to change the password= , or better ship units with unique and secure passwords, especially irrit= ating since many modems actually run linux inside...) >>>>>> >>>>>>>> Routerstats is not reliant on telnet. >>>>>> Ah, I see it only extracts "Downstream Noise Margin and Connec= tion Speed", I now see why you recommend the use of SNRM as proxy for lin= e-quality ;)... >>>>>> >>>>>> >>>>>>>> I appreciate the analysis, which I am sure is correct. >>>>>> I certainly hope it is, but while phrased as statements instea= d of questions, I might be completely out for lunch here; then gain I am = always happy to learn from my mistakes... >>>>>> >>>>>>>> I am interested in external RF interference primarily. I have ha= d two episodes of possible interference recently, leading to transient d= isconnections. >>>>>> Well, especially for RF interference a time resolved plot of C= RCs, HECs, and even FECs (which should also increase massively around noi= se events) would be even better. Also some modems give ES (errored second= s) and SES (severely errored seconds) which are also good to plot along t= ime. >>>>>> >>>>>>>> Continuously monitoring noise margin not only tells you when you= r neighbours get up, but also what is happening 40km above. >>>>>>>> >>>>>>>> The thought was that it would be useful for others, to measure = noise margin to track whether the phenomenon I am noticing when this one = new build of ceroWRT was released - transient disconnection - is related = to that build, or not. I am hoping for longer term benefits also. >>>>>> Mmmh, if the modem concurrently looses sync than cerowrt shoul= d be innocent, if sync stays up and you have PPPoE errors (and run PPPoE = from cerowrt) only with a certain cerowrt build you have a strong case fo= r cero's involvement. >>>>>> >>>>>>>> When David P says his speed has increased, I listen. Here, I upg= raded ceroWRT and had a transient rise in WAN sync speed almost immediate= ly before the first connection loss. >>>>>> You have an open profile (I mean you are limited by line physi= cs and not throttled below that by your ISP), right? If all your neighbor= s switch of their modems and your intermittent RF noise source also sleep= s, you will get a high sync value where all frequency bins are maximally = used (so only little room for bitswitching). Now either cross-talk increa= ses due to mode xDSL activity at your DSLAM or the RF noise comes back. N= ow your sync is exceeding the new line capacity caused by the changed lin= e conditions and there goes your sync. Then on resync with the new condit= ions the system syncs at lower bandwidth to honor the specified SNRM unde= r the new conditions, and you have again only a little leeway for bit swi= tching, but yuo start at a level better matched to your average line cond= ition, so this works better than basically the same amount of spare bits = after a sync with perfect conditions. >>>>>> Now this only applied if there was a resync of the modem after= re-installation of cerowrt=85 If you did not re-sync (either you or the = modem by its own) then it gets puzzling, as all cerowrt does, if I rememb= er your setup correctly, is to do the PPPoE encapsulation, and that shoul= d not affect your speed one iota. >>>>>> (That said, there seems to be a buggy BRAS version by cisco ar= ound, that in germany causes people on old ADSL DSLAMs that hook up to th= e ATM concentration net to get throttled by the BRAS by reducing the PPPo= E en- and decapsulation speed. But that is so obscure that I do not think= it affects you, heck it might be a pure duetsche telekom issue). >>>>>> >>>>>>>> Coincidence or not, the only way to know is by someone, somewher= e, monitoring their connection. >>>>>> I fully endorse that! Monitoring the DSL statistics is a good = practice (I would love doing it again, but my current modem-router has no= meaning flu way of doing that=85) >>>>>> >>>>>> >>>>>> Best Regards >>>>>> Sebastian >>>>>> >>>>>> >>>>>>>> >>>>>>>> On 20/02/14 09:05, Sebastian Moeller wrote: >>>>>>>>> Hi Fred, >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 20, 2014, at 06:28 , Fred Stratton wrote: >>>>>>>>> >>>>>>>>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite >>>>>>>>>> >>>>>>>>>> is software that is useful for monitoring an ADSL connection. = When 'speed has increased' is mentioned, I wonder what has happened to th= e downstream noise margin. >>>>>>>>> I think, DP reported speed increase of the wireless (swN0) = to wired (se00) subnets on his home network, not necessarily increases in= wan speed... >>>>>>>>> >>>>>>>>> Interesting point though; I think with DSL there is a weak = correlation between link stability/speed with noise margin. But other var= iables should have stronger correlation with useable bandwidth than noise= margin. >>>>>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is= not in use, so generally speaking the sync speed of a typical DSL link w= ill over time degrade (and not increase, ignoring G.inp). So once a DSL c= onnection has "aged" down to stable conditions, noise margin what ever th= e numerical values are will not affect the speed. (Note typically the noi= se margin is something that is configured in the DSLAM/modem as minimums;= each frequency bin is only maximally loaded with bits that this minimum = signal to noise margin remains. If the link is throttled below full sync = speeds, say by contract, e.g. having a 6M plan on a short line that would= support 16M, then the noise margin will be large and the system has lots= of freedom how many bits to load on each frequency bin. If the link is r= unning at full sync, basically close to the physical limits of the link t= he noise margin will be close to the minimum values configured by the ISP= =2E If the physical condition change, say more cross-talk noise due to mo= re active DSL links in the DSLAM/trunk line the modem in the second situa= tion will probably loose sync and resync at lower bandwidth but with nois= e margin still at the configured minimum. In other words in that situatio= n noise margin will not correlate with link speed). >>>>>>>>> However CRC and HEC error counts should correlate well with= perceived speed changes, as both require packet retransmissions (visible= to the ensures network stack, basically those packets are just dropped r= educing good put, but at least the end nodes have a good understanding wh= at is pushed over the DSL wires) degrading the good put of the link. Gran= ted, with a low noise margin CRCs are more likely, but it is the errors a= nd not the noise margin that actually affect the speed. (And lo and behol= d with some interference sources even very large noise margins do not pre= vent CRCs sufficiently). >>>>>>>>> Note the number of FECs (forward error correction) is irrel= evant to the speed, as the link carries the FEC information anyway, so no= slowdown for FEC (well, actually with G.inp that changes a bit, as now t= he physical layer tries to retransmit packets/atm cells garbled beyond re= cognition by noise; effectively reducing the link throughput in an opaque= way for the endnotes. Which will cause issues with using a shaper not in= timately linked to the actual xDSL modem. But I have only glanced over ht= tps://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-G.998.4-201006-= I!!PDF-E&type=3Ditems so I might be too pessimistic). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Runs prettily under Wine, and is maintained, unlike DMT. >>>>>>>>> A great, just to complete the list for some broadcom models= : http://www.s446074245.websitehome.co.uk under active development... >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> Sebastian >>>>>>>>> >>>>>>>>>> On 19/02/14 16:38, David Personette wrote: >>>>>>>>>>> I check for updates to certain projects each morning... I can= quit anytime I want... =3D) >>>>>>>>>>> >>>>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have = been fixed, I'll do so tonight. Thanks again. >>>>>>>>>>> >>>>>>>>>>> --=20 >>>>>>>>>>> David P. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 19, 2014 at 11:29 AM, Dave Taht wrote: >>>>>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette wrote: >>>>>>>>>>>> I installed 3.10.28-12, and other than some missing packages= (bash and curl >>>>>>>>>>> Heh. What do you guys do, have a cron job polling for changes= to the build dir? >>>>>>>>>>> :) >>>>>>>>>>> >>>>>>>>>>> I was going to sit on that and put out a more polished versio= n sometime in >>>>>>>>>>> the next couple days. >>>>>>>>>>> >>>>>>>>>>>> were what I noticed, and pulled from the previous version >>>>>>>>>>> I killed some big packages while trying to get a new build do= ne faster. >>>>>>>>>>> >>>>>>>>>>> I'll sort through the missing ones and add them back in. (I a= lso just >>>>>>>>>>> added in squid, per request). Got a big build box donated to = use >>>>>>>>>>> again, post disaster. >>>>>>>>>>> >>>>>>>>>>> Does anyone care about cups? (printing?) It was one of those = things that >>>>>>>>>>> just barely works in the first place due to memory constraint= s and a PITA >>>>>>>>>>> and I haven't shipped it in a while. Most printers are networ= k capable >>>>>>>>>>> these days, and what I tend to use the usb port for is odd de= vices >>>>>>>>>>> and gps and the like. I'd like to have support for a 3g modem= or two... >>>>>>>>>>> >>>>>>>>>>> Two concerns of mine are that I killed off udev, which used t= o manage >>>>>>>>>>> hotplugging. I'd like to know what, if anything, people are u= sing the usb >>>>>>>>>>> for, so as to be able to make sure losing udev doesn't break = that... >>>>>>>>>>> >>>>>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on= WiFi from my >>>>>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank y= ou. >>>>>>>>>>> I still think there is some tuning to be done on a rrul load,= but we had >>>>>>>>>>> to get the last of the instruction traps out of the way first= =2E As of >>>>>>>>>>> this morning >>>>>>>>>>> so far as I know, the "last" ones are gone, but I don't want = to jinx it... >>>>>>>>>>> >>>>>>>>>>> Did you try ipv6? Default routes are not quite working for me= in >>>>>>>>>>> a couple scenarios. >>>>>>>>>>> >>>>>>>>>>>> --=20 >>>>>>>>>>>> David P. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht wrote: >>>>>>>>>>>>> ok, so all the bits flying in loose formation have been reb= ased on top of >>>>>>>>>>>>> openwrt head, and I've submitted the last remaining differe= nces (besides >>>>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one... >>>>>>>>>>>>> >>>>>>>>>>>>> I also went poking through current 3.14rc kernels to find b= ugs fixed there >>>>>>>>>>>>> but >>>>>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhere = in the flow >>>>>>>>>>>>> hash that I had >>>>>>>>>>>>> just submitted upstream, sigh). Tried to backport sch_fq an= d sch_hhf, >>>>>>>>>>>>> failed, >>>>>>>>>>>>> gave up on tracking pie further. >>>>>>>>>>>>> >>>>>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, = tested the >>>>>>>>>>>>> components, >>>>>>>>>>>>> and was ready to release... >>>>>>>>>>>>> >>>>>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a ne= w build now... >>>>>>>>>>>>> >>>>>>>>>>>>> and taking the rest of the day off. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Dave T=E4ht >>>>>>>>>>>>> >>>>>>>>>>>>> Fixing bufferbloat with cerowrt: >>>>>>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Cerowrt-devel mailing list >>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net >>>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>>>>>>>> --=20 >>>>>>>>>>> Dave T=E4ht >>>>>>>>>>> >>>>>>>>>>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cero= wrt/subscribe.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Cerowrt-devel mailing list >>>>>>>>>>> >>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net >>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>>>>>>> _______________________________________________ >>>>>>>>>> Cerowrt-devel mailing list >>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net >>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>