From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 47F4B21F22E for ; Fri, 21 Feb 2014 06:18:11 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5CC6020C10; Fri, 21 Feb 2014 09:18:09 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 21 Feb 2014 09:18:09 -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=4lKXnekL4G3ypUxMMxJxdibTJQw=; b=OWWwT3pTV8dPIjC+usk/H4DfA3V+ 3va6GYCP9VwTgQuhgVhEQImerX7tZzdUBsnC5DGGKTZ9lOZ03F4iquO7kpo0zv9v FNZ7Oo8Zz8yTPNLVnfLM8DJscWeULZS14AZYN5xMyDJLV7KIvYhfGGgR9MNyRwLP bq6wjgZR7cAZJEs= 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=4lKXnekL4G3ypUxMMxJxdi bTJQw=; b=nbOFIMtaTgXmVK1yKCkkPfS2eMShSeNTmEidEgShBNiLSSrkp15fJ8 7KaoESfAg0pboyCn1PluL7obmCa31sZWYI3eV4fhJ/2VuEnSqMtjOZ8ZN7ASejSO PuEKszltfg2tVe/LuE7PiwNMgXMQBLkwlZCBa/Q/J5GQDP92QuXNk= X-Sasl-enc: 3ZbgSyTBv445LPz3W1fUjchp4ZDuSof9v+5lvuyCtIiK 1392992288 Received: from [172.30.42.8] (unknown [78.145.183.131]) by mail.messagingengine.com (Postfix) with ESMTPA id 61378C00003; Fri, 21 Feb 2014 09:18:08 -0500 (EST) Message-ID: <53075FDD.6040307@imap.cc> Date: Fri, 21 Feb 2014 14:17:01 +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: Rich Brown , 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> <53063A54.9050102@imap.cc> <530668A4.4040604@imap.cc> In-Reply-To: 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: Fri, 21 Feb 2014 14:18:11 -0000 I would encourage ADSL users in America to monitor line statistics.=20 There are also a lot of tricks the consumer can use to improve=20 connection stability, widely discussed and implemented in the UK. I also = continue to be amazed by the practice of using the CPE supplied by the=20 ISP, when experimentation can produce a better solution. On 21/02/14 13:12, Rich Brown wrote: > 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 th= e other, and Presto! You're on the air. I had no idea there were all thes= e 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, >> >> >> On Feb 20, 2014, at 21:42 , Fred Stratton wrote= : >> >>> ADSL2+ is better than ADSL in this context, as you point out. I thoug= ht it was worth trying for a week or two, rather than relying solely on t= he literature. >> So in your tests ADSL came up as the most stable solution, interestin= g, 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 t= o see a time resolved series of SNRM per bin plots during on of your REIN= s... >> >>> The combined VDSL2/ADSL2+ approach is interesting. It is unlikely to = happen here, >> 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= =2E 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. >> >> >>> as BT has an effective monopoly of fibre since its publicly-owned co= mpetitor went bankrupt. >> Yeah, but even BT probably wants to retire its ATM gear and that mean= s replacing all DSLAMs (well the guts of the zDSLAMs). Their backbone mos= t likely is already pure IP and if they can get rid of the ATM gear it wi= ll dave money, so thee is something in it for them ;) >> >>> You must be using Annex M, which here is now mainly for business use,= at extra cost. >> 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 wi= ll be retired in Germany and replaced with carrier voice over IP. So ever= ybody using ISDN (and everyone using DSL and POTS) will need to be switch= ed 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 ;) >> >>> 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+. >> For most users the DSLAMs are fixed to the type sold in the plan, so = switching will most likely not work anyways. >> >>> Although blogic is principal developer in Berlin, the majority of wor= k has been done in Polen. >>> >>> Ich kann Deutsch verstehen, (the British Royal Family is more German = than a BMW) but I find Polish far more difficult. >> Oh, gut, ich kann Deutsch ganz passabel schreiben ;) >> >> Best Regards >> Sebastian >> >>> >>> On 20/02/14 20:08, Sebastian Moeller wrote: >>>> Hi Fred, >>>> >>>> On Feb 20, 2014, at 18:24 , Fred Stratton wro= te: >>>> >>>>> Aha.. beyond the DSLAM... >>>>> >>>>> I was unaware of that BRAS PPPoE issue. >>>> And there is no good reason to be aware of that particular screw-up= :) >>>> >>>>> Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipse= t. The manufacturers firmware allows you to choose ADSL2+, or ADSL2, or A= DSL, 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 a= re 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 modem= s) >>>> >>>>> 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 ha= ve guessed that ADSL2+ would be more resilient against interference (at t= he same bandwidth as ADSL1 it should be more robust, but I assume most mo= dems will trade this additional robustness for higher sync) >>>> >>>>> The 2Wire has far fewer problems with the frequent lease renewals t= he ISP imposes. The TD-W8970 has odd problems. >>>> Did you use openwrt on the TD-W8970 rot stock firmware? >>>> >>>>> You are correct. Most of the telephone cable is shared to the excha= nge. Most properties have a 10-pair cable, where only one pair is used. B= it-swapping is supposed to mitigate against crosstalk. >>>> Yes, but I can only do so much, vectoring will help a lot in that r= egard (by measuring the cross-talk and shaping all signals so that the lo= ok great after experiencing cross-talk; pretty cool technology, but also = a computational expensive way to push the inevitable fiber-to-the-home fu= rther into the future). >>>> >>>>> 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+ ;) ) >>>> >>>>> 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 infr= astructure costs - approx 1.5 milliard euro. All the pit covers say 'NYNE= X' on them. >>>> Well, in germany cable download looks quite nice but the upload wit= h 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 s= hares ~400MBit among its users while VDSL typical shares 1Gbit. >>>> >>>> best regards >>>> Sebastian >>>> >>>>> To get back on-topic, I accept that it is unlikely that cero has af= fected the situation. >>>>> >>>>> >>>>> >>>>> On 20/02/14 14:38, Sebastian Moeller wrote: >>>>>> Hi Fred, >>>>>> >>>>>> On Feb 20, 2014, at 14:57 , Fred Stratton w= rote: >>>>>> >>>>>>> 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 accidental= ly throttles a number of users below their rated bandwidths, rather obscu= re and since restricted to ADSL1 hopefully a legacy issue that will go aw= ay at latest once all ADSL1 line cards are retired... >>>>>> >>>>>>>> I am using a 2Wire 2700 as the bridged connection device. The hi= gher frequency bins, as graphed, as not optimally used. The device uses A= DSL2+. 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 moment= s just does not leave enough slack-bits for worse-case scenarios, hence y= our approach to increase the line tolerance by increasing SNRM to be bett= er 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 specifi= c bandwidth 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 so are not a constant source of RF interference in that sense. >>>>>> Well, evenif everybody uses BT's infrastructure there still can b= e 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 th= e lines to the Serving area interface, and that is sufficient for degrada= tion of your line capacity. Only if your neighbors and you directly conne= ct to two different outdoor slams/msans you would be not affected by thei= r del usage. And if you suspect that they cause true RF interference, tha= t 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 bla= ck art=85 >>>>>> >>>>>> Best Regards >>>>>> Sebastian >>>>>> >>>>>>>> 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, f= or VDSL2 connection monitoring. >>>>>>>>>>> >>>>>>>>>>> I have used an HG 612 with ADSL2plus, but telnet is permanent= ly 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 manufacture= rs to switch to ssh on those devices and allow users to change the passwo= rd, or better ship units with unique and secure passwords, especially irr= itating since many modems actually run linux inside...) >>>>>>>>> >>>>>>>>>>> Routerstats is not reliant on telnet. >>>>>>>>> Ah, I see it only extracts "Downstream Noise Margin and Conn= ection Speed", I now see why you recommend the use of SNRM as proxy for l= ine-quality ;)... >>>>>>>>> >>>>>>>>> >>>>>>>>>>> I appreciate the analysis, which I am sure is correct. >>>>>>>>> I certainly hope it is, but while phrased as statements inst= ead of questions, I might be completely out for lunch here; then gain I a= m 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 transien= t disconnections. >>>>>>>>> Well, especially for RF interference a time resolved plot of= CRCs, HECs, and even FECs (which should also increase massively around n= oise events) would be even better. Also some modems give ES (errored seco= nds) 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 measu= re noise margin to track whether the phenomenon I am noticing when this o= ne new build of ceroWRT was released - transient disconnection - is relat= ed to that build, or not. I am hoping for longer term benefits also. >>>>>>>>> Mmmh, if the modem concurrently looses sync than cerowrt sho= uld be innocent, if sync stays up and you have PPPoE errors (and run PPPo= E 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 immedi= ately before the first connection loss. >>>>>>>>> You have an open profile (I mean you are limited by line phy= sics and not throttled below that by your ISP), right? If all your neighb= ors switch of their modems and your intermittent RF noise source also sle= eps, you will get a high sync value where all frequency bins are maximall= y used (so only little room for bitswitching). Now either cross-talk incr= eases 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 l= ine conditions and there goes your sync. Then on resync with the new cond= itions the system syncs at lower bandwidth to honor the specified SNRM un= der the new conditions, and you have again only a little leeway for bit s= witching, but yuo start at a level better matched to your average line co= ndition, so this works better than basically the same amount of spare bit= s after a sync with perfect conditions. >>>>>>>>> Now this only applied if there was a resync of the modem aft= er re-installation of cerowrt=85 If you did not re-sync (either you or th= e modem by its own) then it gets puzzling, as all cerowrt does, if I reme= mber your setup correctly, is to do the PPPoE encapsulation, and that sho= uld 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 PP= PoE en- and decapsulation speed. But that is so obscure that I do not thi= nk it affects you, heck it might be a pure duetsche telekom issue). >>>>>>>>> >>>>>>>>>>> Coincidence or not, the only way to know is by someone, somew= here, monitoring their connection. >>>>>>>>> I fully endorse that! Monitoring the DSL statistics is a goo= d practice (I would love doing it again, but my current modem-router has = no meaning 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 connectio= n. 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 wea= k correlation between link stability/speed with noise margin. But other v= ariables should have stronger correlation with useable bandwidth than noi= se 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 lin= k will over time degrade (and not increase, ignoring G.inp). So once a DS= L 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 minimu= ms; each frequency bin is only maximally loaded with bits that this minim= um signal to noise margin remains. If the link is throttled below full sy= nc speeds, say by contract, e.g. having a 6M plan on a short line that wo= uld support 16M, then the noise margin will be large and the system has l= ots of freedom how many bits to load on each frequency bin. If the link i= s running at full sync, basically close to the physical limits of the lin= k 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 m= ore active DSL links in the DSLAM/trunk line the modem in the second situ= ation will probably loose sync and resync at lower bandwidth but with noi= se margin still at the configured minimum. In other words in that situati= on noise margin will not correlate with link speed). >>>>>>>>>>>> However CRC and HEC error counts should correlate well wi= th perceived speed changes, as both require packet retransmissions (visib= le 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. Gr= anted, 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 beh= old with some interference sources even very large noise margins do not p= revent CRCs sufficiently). >>>>>>>>>>>> Note the number of FECs (forward error correction) is irr= elevant 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 opaq= ue 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-20100= 6-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 mode= ls: 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... =3D) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I hadn't enabled ipv6 again since the hurricane tunnels ha= ve been 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 packa= ges (bash and curl >>>>>>>>>>>>>> Heh. What do you guys do, have a cron job polling for chan= ges to the build dir? >>>>>>>>>>>>>> :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I was going to sit on that and put out a more polished ver= sion 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 tho= se things that >>>>>>>>>>>>>> just barely works in the first place due to memory constra= ints and a PITA >>>>>>>>>>>>>> and I haven't shipped it in a while. Most printers are net= work 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 mo= dem or two... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Two concerns of mine are that I killed off udev, which use= d to manage >>>>>>>>>>>>>> hotplugging. I'd like to know what, if anything, people ar= e using the usb >>>>>>>>>>>>>> for, so as to be able to make sure losing udev doesn't bre= ak 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. Than= k you. >>>>>>>>>>>>>> I still think there is some tuning to be done on a rrul lo= ad, but we had >>>>>>>>>>>>>> to get the last of the instruction traps out of the way fi= rst. As of >>>>>>>>>>>>>> this morning >>>>>>>>>>>>>> so far as I know, the "last" ones are gone, but I don't wa= nt to jinx it... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Did you try ipv6? Default routes are not quite working for= me in >>>>>>>>>>>>>> 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 = rebased on top of >>>>>>>>>>>>>>>> openwrt head, and I've submitted the last remaining diff= erences (besides >>>>>>>>>>>>>>>> SQM) up to openwrt-devel. They immediately took one... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I also went poking through current 3.14rc kernels to fin= d bugs fixed there >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>> not in stable 3.10. Found two more I think. (one elsewhe= re 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 dnsse= c, 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. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --=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/c= erowrt/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 >>> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel