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

Fred Stratton fredstratton at imap.cc
Thu Feb 20 06:35:47 EST 2014 

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.
>
> Routerstats is not reliant on telnet.
>
> I appreciate the analysis, which I am sure is correct. I am interested 
> in external RF interference primarily. I have had two episodes of 
> possible interference  recently, leading to transient disconnections.
>
> 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.
>
> 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.
>
> Coincidence or not, the only way to know is by someone, somewhere, 
> monitoring their connection.
>
>
>
>
> On 20/02/14 09:05, Sebastian Moeller wrote:
>> 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
>
>

More information about the Cerowrt-devel mailing list