From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 72F4C21F245 for ; Fri, 21 Feb 2014 05:12:45 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id x13so5791126qcv.20 for ; Fri, 21 Feb 2014 05:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nGdwLnX4sovYjnc0Tg1TlBjuiFRZ2fY8Mo5UG/k0ItI=; b=BK5a/b4cwKE7NCayYuy0rapR7Cgu5wH2rAetQoJgaBdrLIcU216fOmIeXkvdnWpaTg cGK31RVTBlZSQqlSSuYhStWgY7z81yRUYDEnhHlLRBm+HTdbYxiJD4f6Eqw96mHW9yer v/C1SRWlGiSWwFwI4N4eb+H6+2grUaONuRNyEqNCsWK0InQw7g4qceXoWKvW9QOqUF1i P1bxlnyiBv8OGamMsS9IJdIzm0vuDElaA+4dIGjApgKd9xS9qAk5J1ftCJ/HFRz9jocN 4B08oV7DGreRA690m6/c7rdOW/2fc3Gby/dD3qDuz5XwmEUtCiqhV/I8RoojbsdBiXz6 p2AQ== X-Received: by 10.224.119.199 with SMTP id a7mr9678583qar.27.1392988364115; Fri, 21 Feb 2014 05:12:44 -0800 (PST) Received: from richs-mbp-3122.home.lan (pool-71-241-132-180.burl.east.myfairpoint.net. [71.241.132.180]) by mx.google.com with ESMTPSA id 3sm21746980qan.15.2014.02.21.05.12.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 05:12:43 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Rich Brown In-Reply-To: Date: Fri, 21 Feb 2014 08:12:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <530668A4.4040604@imap.cc> To: Sebastian Moeller X-Mailer: Apple Mail (2.1827) Cc: cerowrt-devel 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: Fri, 21 Feb 2014 13:12:45 -0000 Hi Fred and Sebastian, I just want to say that I have enjoyed reading this thread. Even though = I'm an electrical engineer by training, I sorta thought DSL "just = worked" - plug the phone line in one side of the modem, plug the router = into the other, and Presto! You're on the air. I had no idea there were = all these considerations. (Fortunately, for customers, my mental model = is pretty close to what you need to know.) Best, Rich On Feb 20, 2014, at 5:18 PM, Sebastian Moeller wrote: > Hi Fred, >=20 >=20 > On Feb 20, 2014, at 21:42 , Fred Stratton = wrote: >=20 >> ADSL2+ is better than ADSL in this context, as you point out. I = thought it was worth trying for a week or two, rather than relying = solely on the literature. >=20 > So in your tests ADSL came up as the most stable solution, = interesting, real data always beats theory. Could well be the actual = modem hardware, ADSL only uses half the frequencies or the modem driver. = Or maybe your RF interferer affects the higher frequencies more. Would = be interesting to see a time resolved series of SNRM per bin plots = during on of your REINs... >=20 >>=20 >> The combined VDSL2/ADSL2+ approach is interesting. It is unlikely to = happen here, >=20 > I think this is the future; ATM equipment is dying and telcos = try to get away from it consolidating on an ethernet based concentration = network. I am not sure whether there are any more new ADSL1 line cards = for non-ATM DSLAMs. But I could be off here as always. >=20 >=20 >> as BT has an effective monopoly of fibre since its publicly-owned = competitor went bankrupt. >=20 > Yeah, but even BT probably wants to retire its ATM gear and that = means replacing all DSLAMs (well the guts of the zDSLAMs). Their = backbone most likely is already pure IP and if they can get rid of the = ATM gear it will dave money, so thee is something in it for them ;) >=20 >>=20 >> You must be using Annex M, which here is now mainly for business use, = at extra cost. >=20 > Well its Annex J (see: = http://en.wikipedia.org/wiki/G.992.3_Annex_J) which deutsche telekom = pushes as it allows coexistence with its old Annex B band plan that = allowed DSL to coexist with ISDN. Both POTS and ISDN will be retired in = Germany and replaced with carrier voice over IP. So everybody using ISDN = (and everyone using DSL and POTS) will need to be switched to all-ip; to = sweeten the change people are also getting annex J which gives a much = better upload than typical for ADSL variants. That is sort of the = publics dividend of the switch to all-ip ;) >=20 >>=20 >> OpenWRT test builds require an older version of uboot than the one = TP-Link uses. There is no easy regression path,and the builds are = immature. They will never allow a choice between ADSL,ADSL2, AND ADSL2+. >=20 > For most users the DSLAMs are fixed to the type sold in the = plan, so switching will most likely not work anyways. >=20 >>=20 >> Although blogic is principal developer in Berlin, the majority of = work has been done in Polen. >>=20 >> Ich kann Deutsch verstehen, (the British Royal Family is more German = than a BMW) but I find Polish far more difficult. >=20 > Oh, gut, ich kann Deutsch ganz passabel schreiben ;) >=20 > Best Regards > Sebastian >=20 >>=20 >>=20 >> On 20/02/14 20:08, Sebastian Moeller wrote: >>> Hi Fred, >>>=20 >>> On Feb 20, 2014, at 18:24 , Fred Stratton = wrote: >>>=20 >>>> Aha.. beyond the DSLAM... >>>>=20 >>>> I was unaware of that BRAS PPPoE issue. >>> And there is no good reason to be aware of that particular = screw-up :) >>>=20 >>>> 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 you 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 least in Germany the trend seems to be combined VDSL2/ADSL2+ line = cards (with ADSL2+ as fall back for long distances and customers with = old modems) >>>=20 >>>> As you would expect ADSL had the least problems, and gave a full 8 = megabits/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 modems will trade this additional robustness for higher sync) >>>=20 >>>> 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? >>>=20 >>>> You are correct. Most of the telephone cable is shared to the = exchange. Most properties have a 10-pair cable, where only one pair is = used. Bit-swapping is supposed to mitigate against crosstalk. >>> Yes, but I can only do so much, vectoring will help a lot in = that regard (by measuring the cross-talk and shaping all signals so that = the look great after experiencing cross-talk; pretty cool technology, = but also a computational expensive way to push the inevitable = fiber-to-the-home further into the future). >>>=20 >>>> Even when FTTC appears, all cables will be adjacent up to the local = MSAN. >>> This is why vectoring, with its promise to eradicate DSLAM NEXT = and line 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 actually quite reasonable for ADSL2+ ;) ) >>>=20 >>>> 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 = infrastructure 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 5M max (2-4 typical) is not quite as good as current VDSL offers = (10up) and definitely way off the promised 40up; also a cable node in = germany shares ~400MBit among its users while VDSL typical shares 1Gbit. >>>=20 >>> best regards >>> Sebastian >>>=20 >>>> To get back on-topic, I accept that it is unlikely that cero has = affected the situation. >>>>=20 >>>>=20 >>>>=20 >>>> On 20/02/14 14:38, Sebastian Moeller wrote: >>>>> Hi Fred, >>>>>=20 >>>>> On Feb 20, 2014, at 14:57 , Fred Stratton = wrote: >>>>>=20 >>>>>> 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 affected, 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... >>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> The 2Wire is very effective at suppressing impulse noise. >>>>>>>=20 >>>>>>> The line is uncapped, with unlimited downloads. >>>>> Just as I remembered, that means that syncing at good line = moments just 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 pity that one can not really request the modem to only sync at a = specific bandwidth directly. >>>>>=20 >>>>>>> The RF Interference source is unknown. Possible culprits are >>>>>>>=20 >>>>>>> analogue to digital set top TV conversion boxes. >>>>>>> passing vehicles. >>>>>>> holes in the ionosphere. >>>>>>>=20 >>>>>>> http://www.bath.ac.uk/elec-eng/invert/iono/rti.html >>>>>>>=20 >>>>>>> I can find no PPPoE errors. >>>>> Then I think that cerowrt should have no effect on the wan = speed. >>>>>=20 >>>>>>> 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 some 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 lines 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 art=85 >>>>>=20 >>>>> Best Regards >>>>> Sebastian >>>>>=20 >>>>>>> On 20/02/14 13:15, Sebastian Moeller wrote: >>>>>>>> Hi Fred, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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 >>>>>>>>=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... >>>>>>>>=20 >>>>>>>>>> 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 >>>>>>>>>> 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=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 >>>>>>>>>> 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) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best Regards >>>>>>>> Sebastian >>>>>>>>=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 >>>>>>>>>>>> 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 >>>>>>>>>>>>> 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 >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel