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.
I can find no PPPoE errors.
are not a constant source of RF interference in that sense.
Post by Sebastian MoellerHi Fred,
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
Post by Sebastian MoellerHi Fred,
Post by Fred Strattonhttp://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).
Post by Fred StrattonRuns prettily under Wine, and is maintained, unlike DMT.
http://www.s446074245.websitehome.co.uk under active development...
Best Regards
Sebastian
Post by Fred StrattonPost by David PersonetteI 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
On Wed, Feb 19, 2014 at 11:11 AM, David Personette
Post by David PersonetteI 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.
Post by David Personettewere 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...
Post by David Personettecomcast/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.
Post by David Personette--
David P.
On Tue, Feb 18, 2014 at 5:49 PM, Dave Taht
Post by Dave Tahtok, 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
http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel