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 <moell...@gmx.de> wrote: > Hi Fred, > > > On Feb 20, 2014, at 21:42 , Fred Stratton <fredstrat...@imap.cc> wrote: > >> 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. > > 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... > >> >> 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. 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 >> competitor went bankrupt. > > 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 ;) > >> >> 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 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 ;) > >> >> 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 work 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 <fredstrat...@imap.cc> wrote: >>> >>>> 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 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) >>> >>>> 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) >>> >>>> 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? >>> >>>> 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). >>> >>>> 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 >>>> 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. >>> >>> best regards >>> Sebastian >>> >>>> To get back on-topic, I accept that it is unlikely that cero has affected >>>> the situation. >>>> >>>> >>>> >>>> On 20/02/14 14:38, Sebastian Moeller wrote: >>>>> Hi Fred, >>>>> >>>>> On Feb 20, 2014, at 14:57 , Fred Stratton <fredstrat...@imap.cc> wrote: >>>>> >>>>>> 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... >>>>> >>>>>>> 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. >>>>> 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… It is a pity >>>>> that one can not really request the modem to only sync at a specific >>>>> 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 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… Since we >>>>> humans have no good sense for electrical fields locating the source of RF >>>>> interferes is a black art… >>>>> >>>>> Best Regards >>>>> Sebastian >>>>> >>>>>>> On 20/02/14 13:15, Sebastian Moeller wrote: >>>>>>>> Hi Fred, >>>>>>>> >>>>>>>> >>>>>>>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstrat...@imap.cc> 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 <fredstrat...@imap.cc> >>>>>>>>>>> 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 <dave.t...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette >>>>>>>>>>>>> <dper...@gmail.com> 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 <dave.t...@gmail.com> >>>>>>>>>>>>>> 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 >>>> >> >> > > _______________________________________________ > 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
