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 1BEA621F224 for ; Thu, 20 Feb 2014 05:58:27 -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 66CCC20A11; Thu, 20 Feb 2014 08:58:26 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 20 Feb 2014 08:58:26 -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=us5MQ9ToKNAoA5Err3PhNTHwEUU=; b=o1HGf9aytImxNVAmg+5HVffwTz7t 4+306mN8ifSAAKz9RG4PARbDCNyZIFkfQTfuofHybUz8AAfrrP0mKGItrSdYyeX6 IlWR+OcMDQcZwbe3Ea89hHUH70W38dhzk8o9ynZQhf6kzcRZTXqJm6iOYwv9J5MC Ib6kDF2Y3+y+hJg= 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=us5MQ9ToKNAoA5Err3PhNT HwEUU=; b=l5DKFS1LWbCJ0XAzW7p0XoMw6Xndt9b8ZoiTm8kBxNycLo8kMGu26c JzZWH6VkJ7ByNKIHxEkMd2sSHqAvNsr9EwM+X2aAu0DNxPLAio/9vNIje3MhUOZe Pz+HL3g0fOr5xD7/lJxwKZ0xp4u7OKjcYLJpMw4x4hqloDYDv9wd0= X-Sasl-enc: xT7oOmjsKBl6XwPyqOUXt5GMCt82hlf4BU3+eRKT386P 1392904705 Received: from [172.30.42.8] (unknown [78.145.42.63]) by mail.messagingengine.com (Postfix) with ESMTPA id 97F05C00003; Thu, 20 Feb 2014 08:58:25 -0500 (EST) Message-ID: <530609BE.6030508@imap.cc> Date: Thu, 20 Feb 2014 13:57:18 +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> In-Reply-To: <5306099C.1090604@xyz.am> Content-Type: text/plain; charset=windows-1252; 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 13:58:33 -0000 On 20/02/14 13:56, Fred Stratton wrote: > The DSLAM at the exchange is an Infineon, Germany's finest. > > 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+. The user cannot change this mode. > > The 2Wire is very effective at suppressing impulse noise. > > The line is uncapped, with unlimited downloads. > > 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. > > The neighbours, based on their SSIDs, are always changing ISPs, and so > are not a constant source of RF interference in that sense. > > > On 20/02/14 13:15, Sebastian Moeller wrote: >> Hi Fred, >> >> >> On Feb 20, 2014, at 12:35 , Fred Stratton wrote: >> >>> 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 irritating since many modems actually run linux inside...) >> >>>> Routerstats is not reliant on telnet. >> Ah, I see it only extracts "Downstream Noise Margin and >> Connection 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 always 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 disconnections. >> Well, especially for RF interference a time resolved plot of >> CRCs, 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 time. >> >>>> 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. >> Mmmh, if the modem concurrently looses sync than cerowrt should >> 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 for cero's involvement. >> >>>> 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. >> 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 used (so only little room for >> bitswitching). Now either cross-talk increases 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 conditions 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 >> switching, but yuo start at a level better matched to your average >> line condition, 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… If you did not re-sync (either you or the >> modem 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 >> around, 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 it 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 >> practice (I would love doing it again, but my current modem-router >> has no meaning flu way of doing that…) >> >> >> 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 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 >>>> > >