Hi Fred,
On Feb 20, 2014, at 18:24 , Fred Stratton <[email protected]> wrote:
Aha.. beyond the DSLAM...
I was unaware of that BRAS PPPoE issue.
And there is no good reason to be aware of that particular screw-up :)
Before using the 2Wire, I was using aTD-W9870, with a Lantiq chipset. The
manufacturers firmware allows you to choose ADSL2+, or ADSL2, or ADSL,
specifically.
My observation in the past was that the DSLAM has to play along; if you
try ADSL2 on a ADSL1 line card it will just not sync. Now the ISPs are free to
expose several modes on the same line card if they want to. At least in Germany
the trend seems to be combined VDSL2/ADSL2+ line cards (with ADSL2+ as fall
back for long distances and customers with old modems)
As you would expect ADSL had the least problems, and gave a full 8 megabits/s.
I could easily be off, but from looking at the standards I would have
guessed that ADSL2+ would be more resilient against interference (at the same
bandwidth as ADSL1 it should be more robust, but I assume most modems will
trade this additional robustness for higher sync)
The 2Wire has far fewer problems with the frequent lease renewals the ISP
imposes. The TD-W8970 has odd problems.
Did you use openwrt on the TD-W8970 rot stock firmware?
You are correct. Most of the telephone cable is shared to the exchange. Most
properties have a 10-pair cable, where only one pair is used. Bit-swapping is
supposed to mitigate against crosstalk.
Yes, but I can only do so much, vectoring will help a lot in that
regard (by measuring the cross-talk and shaping all signals so that the look
great after experiencing cross-talk; pretty cool technology, but also a
computational expensive way to push the inevitable fiber-to-the-home further
into the future).
Even when FTTC appears, all cables will be adjacent up to the local MSAN.
This is why vectoring, with its promise to eradicate DSLAM NEXT and
line FEXT almost completely, is going to help a lot. Since fiber is not an
option, I am looking forward to switching to that, 100Mbit in 40 Mbit out also
is a much saner asymmetry than my current 16in 2.5 out (which is actually quite
reasonable for ADSL2+ ;) )
I doubt I shall go that route. I have cable outside the front door already,
which nobody uses, as they are still trying to recoup their infrastructure
costs - approx 1.5 milliard euro. All the pit covers say 'NYNEX' on them.
Well, in germany cable download looks quite nice but the upload with 5M
max (2-4 typical) is not quite as good as current VDSL offers (10up) and
definitely way off the promised 40up; also a cable node in germany shares
~400MBit among its users while VDSL typical shares 1Gbit.
best regards
Sebastian
To get back on-topic, I accept that it is unlikely that cero has affected the
situation.
On 20/02/14 14:38, Sebastian Moeller wrote:
Hi Fred,
On Feb 20, 2014, at 14:57 , Fred Stratton <[email protected]> wrote:
On 20/02/14 13:56, Fred Stratton wrote:
The DSLAM at the exchange is an Infineon, Germany's finest.
The issue I mentioned did not happen at the DSLAM so sync was not
affected, but at the PPPoE termination point, the BRAS, which accidentally
throttles a number of users below their rated bandwidths, rather obscure and
since restricted to ADSL1 hopefully a legacy issue that will go away at latest
once all ADSL1 line cards are retired...
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.
Just as I remembered, that means that syncing at good line moments just
does not leave enough slack-bits for worse-case scenarios, hence your approach
to increase the line tolerance by increasing SNRM to be better equipped for
your sync to survive the interference episodes… It is a pity that one can not
really request the modem to only sync at a specific bandwidth directly.
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.
Then I think that cerowrt should have no effect on the wan speed.
The neighbours, based on their SSIDs, are always changing ISPs, and so are not
a constant source of RF interference in that sense.
Well, evenif everybody uses BT's infrastructure there still can be some
shared cable segments which can cause cross-talk. So even a local loop
unbundled ISP that runs its own DSLAM-lincards at the central office will have
some of its wire share a bundle with other ISP's wire along the lines to the
Serving area interface, and that is sufficient for degradation of your line
capacity. Only if your neighbors and you directly connect to two different
outdoor slams/msans you would be not affected by their del usage. And if you
suspect that they cause true RF interference, that can come easily in via the
power lines… Since we humans have no good sense for electrical fields locating
the source of RF interferes is a black art…
Best Regards
Sebastian
On 20/02/14 13:15, Sebastian Moeller wrote:
Hi Fred,
On Feb 20, 2014, at 12:35 , Fred Stratton <[email protected]> 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 <[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
