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 5C91321F240 for ; Thu, 20 Feb 2014 03:37:00 -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 238EB20B17; Thu, 20 Feb 2014 06:36:55 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 20 Feb 2014 06:36:55 -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=Rz0ENkzxEd0HIQP5rkkGwwhbQq0=; b=gcCV/8Yve4RVzUGxH60oFlphWuXQ 9tCFGFglEwrDwPlPNkqq/a0lbr3aONVoCGDvL22g6E8YG1Ci6JDnWBHQ20+DQJ1V Ny06EfpN/Z2HdVSCCnCvFkopgSxjjgggNxskJuz4JFFtbkl/XsT932YVbXsSycRY sx3WSJ/I7i0JP4U= 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=Rz0ENkzxEd0HIQP5rkkGww hbQq0=; b=uBMf2HFpFZhXu34glSx9rd69jhqvynVWaa6K53ye97UNByAQUlErDu UyugEAzXgq89LCTHi3/pGow2gF1p51HcnJ66etzSBEC3cHSTr7Ga61GxFtOLF/yG axODXXAVoGbBWm2Y1Fu3EB1GSQWkw4ES8EErfENts1jcKq1TmwvcQ= X-Sasl-enc: K0faDePhd+ZMye8S6g8vGJ3H2t6M0KncOVy0BobykonU 1392896214 Received: from [172.30.42.8] (unknown [78.145.42.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 56B2CC007AC; Thu, 20 Feb 2014 06:36:54 -0500 (EST) Message-ID: <5305E893.8020604@imap.cc> Date: Thu, 20 Feb 2014 11:35:47 +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> In-Reply-To: <5305E875.9070508@imap.cc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 11:37:01 -0000 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. > > Routerstats is not reliant on telnet. > > I appreciate the analysis, which I am sure is correct. I am interested > in external RF interference primarily. I have had two episodes of > possible interference recently, leading to transient disconnections. > > 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 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. > > When David P says his speed has increased, I listen. Here, I upgraded > ceroWRT and had a transient rise in WAN sync speed almost immediately > before the first connection loss. > > Coincidence or not, the only way to know is by someone, somewhere, > monitoring their connection. > > > > > 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 >>> 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 wan speed... >> >> Interesting point though; I think with DSL there is a weak >> correlation between link stability/speed with noise margin. But other >> variables 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 >> will over time degrade (and not increase, ignoring G.inp). So once a >> DSL connection 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; 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 running 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 active 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 margin still at the configured minimum. In >> other words in that situation 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 reducing 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. Granted, 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 prevent CRCs sufficiently). >> Note the number of FECs (forward error correction) is irrelevant >> 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 the physical layer tries to retransmit packets/atm cells garbled >> beyond recognition by noise; effectively reducing the link throughput >> in an opaque way for the endnotes. Which will cause issues with using >> a shaper not intimately linked to the actual xDSL modem. But I have >> only glanced over >> https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-I!!PDF-E&type=items >> 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... =) >>>> >>>> I hadn't enabled ipv6 again since the hurricane tunnels have been >>>> fixed, I'll do so tonight. Thanks again. >>>> >>>> -- >>>> 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 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 also 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 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 devices >>>> 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 to manage >>>> hotplugging. I'd like to know what, if anything, people are using >>>> 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 you. >>>> 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. 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. >>>> >>>>> -- >>>>> 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 rebased >>>>>> on top of >>>>>> openwrt head, and I've submitted the last remaining differences >>>>>> (besides >>>>>> SQM) up to openwrt-devel. They immediately took one... >>>>>> >>>>>> I also went poking through current 3.14rc kernels to find bugs >>>>>> 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, tested >>>>>> 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. >>>>>> >>>>>> >>>>>> -- >>>>>> Dave Täht >>>>>> >>>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> Dave Täht >>>> >>>> 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 >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > >