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 <[email protected]> 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 <[email protected]>
wrote:
On Wed, Feb 19, 2014 at 11:11 AM, David Personette
<[email protected]> 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 <[email protected]>
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
[email protected]
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
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
