From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B6C36201B8F for ; Thu, 20 Feb 2014 05:15:57 -0800 (PST) Received: from u-089-d005.biologie.uni-tuebingen.de ([134.2.89.5]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M2ts6-1X5poS1a10-00saZ7 for ; Thu, 20 Feb 2014 14:15:54 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: <5305E893.8020604@imap.cc> Date: Thu, 20 Feb 2014 14:15:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53059269.1000300@imap.cc> <5305E875.9070508@imap.cc> <5305E893.8020604@imap.cc> To: Fred Stratton X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:ErcaDfOwcM0/LDklBCsd8XNHiup3GefEtQKVdQIYYghA8lqeT8u HujZzRREYcfxZ6nYGyUuv9XqPRrUSwBniHorjDDHW9tQOdNvw6ukQBYvkAf+6AlZzMb4dDS KgKnu5IbXYOv8kChPK/o/IV1if5EwlqCZ7Tfv9/vPjkAmjKFoZ0lqmH1gqLvJttZKoO/iKS oB9sNK9IF0sYQGlVneAOQ== Cc: cerowrt-devel@lists.bufferbloat.net 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:15:58 -0000 Hi Fred, On Feb 20, 2014, at 12:35 , Fred Stratton wrote: >=20 > On 20/02/14 11:35, Fred Stratton wrote: >> I am aware of the DSLStats executable produced by Bald_Eagle on Kitz. >>=20 >> This was designed primarily with the Huawei HG 612 in mind, for VDSL2 = connection monitoring. >>=20 >> 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...) >>=20 >> 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 ;)... >>=20 >> 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. >>=20 >> Continuously monitoring noise margin not only tells you when your = neighbours get up, but also what is happening 40km above. >>=20 >> 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.=20 >>=20 >> 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.=20 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 = 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).=20= >>=20 >> 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=85) Best Regards Sebastian >>=20 >>=20 >>=20 >>=20 >> On 20/02/14 09:05, Sebastian Moeller wrote: >>> Hi Fred, >>>=20 >>>=20 >>> On Feb 20, 2014, at 06:28 , Fred Stratton = wrote: >>>=20 >>>> http://www.vwlowen.co.uk/internet/files.htm#routerstatslite >>>>=20 >>>> 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... >>>=20 >>> 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=3De&id=3DT-REC-G.998.4-201006= -I!!PDF-E&type=3Ditems so I might be too pessimistic). >>>=20 >>>=20 >>>=20 >>>> 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... >>>=20 >>>=20 >>> Best Regards >>> Sebastian >>>=20 >>>>=20 >>>>=20 >>>> 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) >>>>>=20 >>>>> I hadn't enabled ipv6 again since the hurricane tunnels have been = fixed, I'll do so tonight. Thanks again. >>>>>=20 >>>>> --=20 >>>>> David P. >>>>>=20 >>>>>=20 >>>>> 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? >>>>> :) >>>>>=20 >>>>> I was going to sit on that and put out a more polished version = sometime in >>>>> the next couple days. >>>>>=20 >>>>>> were what I noticed, and pulled from the previous version >>>>> I killed some big packages while trying to get a new build done = faster. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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... >>>>>=20 >>>>> 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... >>>>>=20 >>>>>> 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... >>>>>=20 >>>>> Did you try ipv6? Default routes are not quite working for me in >>>>> a couple scenarios. >>>>>=20 >>>>>> --=20 >>>>>> David P. >>>>>>=20 >>>>>>=20 >>>>>> 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... >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> So I got a new build going, including dnsmasq with dnssec, = tested the >>>>>>> components, >>>>>>> and was ready to release... >>>>>>>=20 >>>>>>> ... when a whole boatload of other stuff landed. Doing a new = build now... >>>>>>>=20 >>>>>>> and taking the rest of the day off. >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> Dave T=E4ht >>>>>>>=20 >>>>>>> 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 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Dave T=E4ht >>>>>=20 >>>>> Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Cerowrt-devel mailing list >>>>>=20 >>>>> 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 >>=20 >>=20 >=20