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 5B5662007D0 for ; Thu, 20 Feb 2014 09:25:47 -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 B02F3210A5; Thu, 20 Feb 2014 12:25:44 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 20 Feb 2014 12:25:44 -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=k85hx6gN++BT7rDhGRMN6VRLhZY=; b=gCJ1A4TsOyNfKJCKjs4LQ7b8dZrb qEjd2hvCxSsiqyuQfF4FBNG4bss0x9CIIsF626rxC+wVfKsIvDf3Wv1iZgtzEa2V v7W1LfIw+aTdX9z0WTmkVl6E/Ppb1V5ED/iCWttLXXrr39sDSdpHPs+2Uo34Xth+ pq5O+IvEjdsgl4I= 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=k85hx6gN++BT7rDhGRMN6V RLhZY=; b=UQaCwsb8plCjnvge3PMbrO71X7qjmiUEpgbg7+VL0Db6QlJQEASP3W e3XGpEjEwwF7JeURMlXWCLFNNzGG8d3ks916Oehg6uWtp83G8oIBPrSgHmzq5Yhr j5div1l4UXw/jrE6RfAYf7wFVQUtCXb0iYBjjezwGjwhs8W3Dhhrc= X-Sasl-enc: J1dsPHR8vLAUoUcEHUUYFpHpksXutmMc+2l8fR9Bi8Gz 1392917144 Received: from [172.30.42.8] (unknown [78.145.42.63]) by mail.messagingengine.com (Postfix) with ESMTPA id A509AC007B5; Thu, 20 Feb 2014 12:25:43 -0500 (EST) Message-ID: <53063A54.9050102@imap.cc> Date: Thu, 20 Feb 2014 17:24:36 +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> In-Reply-To: <5FCE9372-5DCD-4CDD-885C-706B5A7F19A2@gmx.de> 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 17:25:47 -0000 Aha.. beyond the DSLAM... I was unaware of that BRAS PPPoE issue. Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipset.=20 The manufacturers firmware allows you to choose ADSL2+, or ADSL2, or=20 ADSL, specifically. As you would expect ADSL had the least problems, and gave a full 8=20 megabits/s. The 2Wire has far fewer problems with the frequent lease renewals the=20 ISP imposes. The TD-W8970 has odd problems. You are correct. Most of the telephone cable is shared to the exchange.=20 Most properties have a 10-pair cable, where only one pair is used.=20 Bit-swapping is supposed to mitigate against crosstalk. Even when FTTC appears, all cables will be adjacent up to the local=20 MSAN. I doubt I shall go that route. I have cable outside the front door = already, which nobody uses, as they are still trying to recoup their=20 infrastructure costs - approx 1.5 milliard euro. All the pit covers say=20 'NYNEX' on them. To get back on-topic, I accept that it is unlikely that cero has=20 affected the situation. On 20/02/14 14:38, Sebastian Moeller wrote: > Hi Fred, > > On Feb 20, 2014, at 14:57 , Fred Stratton wrote:= > >> 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 affe= cted, but at the PPPoE termination point, the BRAS, which accidentally th= rottles a number of users below their rated bandwidths, rather obscure an= d 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 higher = frequency bins, as graphed, as not optimally used. The device uses ADSL2+= =2E 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 jus= t does not leave enough slack-bits for worse-case scenarios, hence your a= pproach to increase the line tolerance by increasing SNRM to be better eq= uipped for your sync to survive the interference episodes=85 It is a pity= that one can not really request the modem to only sync at a specific ban= dwidth 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 s= o are not a constant source of RF interference in that sense. > Well, evenif everybody uses BT's infrastructure there still can be som= e shared cable segments which can cause cross-talk. So even a local loop = unbundled ISP that runs its own DSLAM-lincards at the central office will= have some of its wire share a bundle with other ISP's wire along the lin= es to the Serving area interface, and that is sufficient for degradation = 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 del= usage. And if you suspect that they cause true RF interference, that can= come easily in via the power lines=85 Since we humans have no good sense= for electrical fields locating the source of RF interferes is a black ar= t=85 > > Best Regards > Sebastian > >>> >>> On 20/02/14 13:15, Sebastian Moeller wrote: >>>> Hi Fred, >>>> >>>> >>>> On Feb 20, 2014, at 12:35 , Fred Stratton wro= te: >>>> >>>>> On 20/02/14 11:35, Fred Stratton wrote: >>>>>> I am aware of the DSLStats executable produced by Bald_Eagle on Ki= tz. >>>>>> >>>>>> This was designed primarily with the Huawei HG 612 in mind, for VD= SL2 connection monitoring. >>>>>> >>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanently av= ailable, with the password 'admin', a feature I do not like, even on a br= idged device. >>>> Ah, that sounds not very safe (would it hurt the manufacturers t= o switch to ssh on those devices and allow users to change the password, = or better ship units with unique and secure passwords, especially irritat= ing since many modems actually run linux inside...) >>>> >>>>>> Routerstats is not reliant on telnet. >>>> Ah, I see it only extracts "Downstream Noise Margin and Connecti= on Speed", I now see why you recommend the use of SNRM as proxy for line-= quality ;)... >>>> >>>> >>>>>> I appreciate the analysis, which I am sure is correct. >>>> I certainly hope it is, but while phrased as statements instead = of questions, I might be completely out for lunch here; then gain I am al= ways happy to learn from my mistakes... >>>> >>>>>> I am interested in external RF interference primarily. I have had = two episodes of possible interference recently, leading to transient dis= connections. >>>> Well, especially for RF interference a time resolved plot of CRC= s, HECs, and even FECs (which should also increase massively around noise= events) would be even better. Also some modems give ES (errored seconds)= and SES (severely errored seconds) which are also good to plot along tim= e. >>>> >>>>>> Continuously monitoring noise margin not only tells you when your = neighbours get up, but also what is happening 40km above. >>>>>> >>>>>> The thought was that it would be useful for others, to measure no= ise margin to track whether the phenomenon I am noticing when this one ne= w 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 should = be innocent, if sync stays up and you have PPPoE errors (and run PPPoE fr= om cerowrt) only with a certain cerowrt build you have a strong case for = cero's involvement. >>>> >>>>>> When David P says his speed has increased, I listen. Here, I upgra= ded ceroWRT and had a transient rise in WAN sync speed almost immediately= before the first connection loss. >>>> You have an open profile (I mean you are limited by line physics= and not throttled below that by your ISP), right? If all your neighbors = switch of their modems and your intermittent RF noise source also sleeps,= you will get a high sync value where all frequency bins are maximally us= ed (so only little room for bitswitching). Now either cross-talk increase= s due to mode xDSL activity at your DSLAM or the RF noise comes back. Now= your sync is exceeding the new line capacity caused by the changed line = conditions and there goes your sync. Then on resync with the new conditio= ns the system syncs at lower bandwidth to honor the specified SNRM under = the new conditions, and you have again only a little leeway for bit switc= hing, but yuo start at a level better matched to your average line condit= ion, so this works better than basically the same amount of spare bits af= ter a sync with perfect conditions. >>>> Now this only applied if there was a resync of the modem after r= e-installation of cerowrt=85 If you did not re-sync (either you or the mo= dem by its own) then it gets puzzling, as all cerowrt does, if I remember= your setup correctly, is to do the PPPoE encapsulation, and that should = not affect your speed one iota. >>>> (That said, there seems to be a buggy BRAS version by cisco arou= nd, that in germany causes people on old ADSL DSLAMs that hook up to the = ATM concentration net to get throttled by the BRAS by reducing the PPPoE = en- and decapsulation speed. But that is so obscure that I do not think i= t affects you, heck it might be a pure duetsche telekom issue). >>>> >>>>>> Coincidence or not, the only way to know is by someone, somewhere,= monitoring their connection. >>>> I fully endorse that! Monitoring the DSL statistics is a good pr= actice (I would love doing it again, but my current modem-router has no m= eaning 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. Wh= en 'speed has increased' is mentioned, I wonder what has happened to the = 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 w= an speed... >>>>>>> >>>>>>> Interesting point though; I think with DSL there is a weak co= rrelation between link stability/speed with noise margin. But other varia= bles should have stronger correlation with useable bandwidth than noise m= argin. >>>>>>> Here is why; as far as I know seamless rate adaptation (SRA) is n= ot in use, so generally speaking the sync speed of a typical DSL link wil= l over time degrade (and not increase, ignoring G.inp). So once a DSL con= nection has "aged" down to stable conditions, noise margin what ever the = numerical values are will not affect the speed. (Note typically the noise= margin is something that is configured in the DSLAM/modem as minimums; e= ach frequency bin is only maximally loaded with bits that this minimum si= gnal to noise margin remains. If the link is throttled below full sync sp= eeds, say by contract, e.g. having a 6M plan on a short line that would s= upport 16M, then the noise margin will be large and the system has lots o= f freedom how many bits to load on each frequency bin. If the link is run= ning at full sync, basically close to the physical limits of the link the= noise margin will be close to the minimum values configured by the ISP. = If the physical condition change, say more cross-talk noise due to more a= ctive DSL links in the DSLAM/trunk line the modem in the second situation= will probably loose sync and resync at lower bandwidth but with noise ma= rgin still at the configured minimum. In other words in that situation no= ise margin will not correlate with link speed). >>>>>>> However CRC and HEC error counts should correlate well with p= erceived speed changes, as both require packet retransmissions (visible t= o the ensures network stack, basically those packets are just dropped red= ucing good put, but at least the end nodes have a good understanding what= is pushed over the DSL wires) degrading the good put of the link. Grante= d, with a low noise margin CRCs are more likely, but it is the errors and= not the noise margin that actually affect the speed. (And lo and behold = with some interference sources even very large noise margins do not preve= nt CRCs sufficiently). >>>>>>> Note the number of FECs (forward error correction) is irrelev= ant to the speed, as the link carries the FEC information anyway, so no s= lowdown for FEC (well, actually with G.inp that changes a bit, as now the= physical layer tries to retransmit packets/atm cells garbled beyond reco= gnition by noise; effectively reducing the link throughput in an opaque w= ay for the endnotes. Which will cause issues with using a shaper not inti= mately linked to the actual xDSL modem. But I have only glanced over http= s://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 q= uit anytime I want... =3D) >>>>>>>>> >>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels have be= en 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 t= o the build dir? >>>>>>>>> :) >>>>>>>>> >>>>>>>>> I was going to sit on that and put out a more polished version = 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 done= faster. >>>>>>>>> >>>>>>>>> I'll sort through the missing ones and add them back in. (I als= o just >>>>>>>>> added in squid, per request). Got a big build box donated to us= e >>>>>>>>> again, post disaster. >>>>>>>>> >>>>>>>>> Does anyone care about cups? (printing?) It was one of those th= ings that >>>>>>>>> just barely works in the first place due to memory constraints = and a PITA >>>>>>>>> and I haven't shipped it in a while. Most printers are network = capable >>>>>>>>> these days, and what I tend to use the usb port for is odd devi= ces >>>>>>>>> and gps and the like. I'd like to have support for a 3g modem o= r two... >>>>>>>>> >>>>>>>>> Two concerns of mine are that I killed off udev, which used to = manage >>>>>>>>> hotplugging. I'd like to know what, if anything, people are usi= ng the usb >>>>>>>>> for, so as to be able to make sure losing udev doesn't break th= at... >>>>>>>>> >>>>>>>>>> comcast/3.10.28-4). It's working great for me. Throughput on W= iFi from my >>>>>>>>>> laptap to wired server is up, from 7-9MB to 10-12MB. Thank you= =2E >>>>>>>>> I still think there is some tuning to be done on a rrul load, b= ut we had >>>>>>>>> to get the last of the instruction traps out of the way first. = 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 i= n >>>>>>>>> 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 rebas= ed on top of >>>>>>>>>>> openwrt head, and I've submitted the last remaining differenc= es (besides >>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one... >>>>>>>>>>> >>>>>>>>>>> I also went poking through current 3.14rc kernels to find bug= s 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 and = sch_hhf, >>>>>>>>>>> failed, >>>>>>>>>>> gave up on tracking pie further. >>>>>>>>>>> >>>>>>>>>>> So I got a new build going, including dnsmasq with dnssec, te= sted the >>>>>>>>>>> components, >>>>>>>>>>> and was ready to release... >>>>>>>>>>> >>>>>>>>>>> ... when a whole boatload of other stuff landed. Doing a new = 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/cerowr= t/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 >>>