[Cerowrt-devel] just when I thought it was safe to do a release

Thu Feb 20 04:05:44 EST 2014

Hi Fred,

On Feb 20, 2014, at 06:28 , Fred Stratton <fredstratton at 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.taht at gmail.com> wrote:
>> On Wed, Feb 19, 2014 at 11:11 AM, David Personette <dperson at 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.taht at 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 at 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 at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel