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

Fred Stratton fredstratton at imap.cc
Thu Feb 20 08:57:18 EST 2014 

On 20/02/14 13:56, Fred Stratton wrote:
> The DSLAM at the exchange is an Infineon, Germany's finest.
>
> 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.
>
> 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.
>
> The neighbours, based on their SSIDs, are always changing ISPs, and so 
> are not a constant source of RF interference in that sense.
>
>
> On 20/02/14 13:15, Sebastian Moeller wrote:
>> Hi Fred,
>>
>>
>> On Feb 20, 2014, at 12:35 , Fred Stratton <fredstratton at 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 <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