Kitz Forum
Broadband Related => ADSL Issues => Topic started by: Weaver on January 12, 2017, 06:19:30 AM
-
This morning I saw my (approx.) all-time fastest ever downstream performance test figures from the speed tester "speedof.me" for my triple ADSL2 line pipe. I saw
7.72 Mbps downstream / 1.08 Mbps upstream
and
7.65 Mbps downstream / 0.99 Mbps upstream
on a second test, conducted very shortly afterwards. These figures are the fastest times obtained from this tester this morning, with a lot of variation being seen - some tests results were only 6.6 Mbps downstream for example - possibly because the network was not completely quiet. It seems to me that a worthwhile approach is to take the highest performance figures in order to throw out any distortions due to local traffic or load on the test server or its pipe.
Other speedtesters gave very different numbers, with speedof.me always reporting the most favourable figures.
I think it is possible that the good downstream figure is either because there is snow lying on the ground - a rarity here - or because the temperatures are (presumably) below freezing at ground level. The current outside temp is 1.1℃.
-
I have to offer a note of caution here. In my experience the speedof.me site is a bit over-generous in its speed figures. When I've used it, on a few occasions it's reported a download speed which is greater than my connection speed. In your case I hope the figures are genuine, but a small pinch of salt is recommended. :)
-
Me too.
http://speedof.me/show.php?img=170112075640-4017.png
Not bad for 40/10 connection, where the best I have seen it deliver is 37/9.25.
-
Me too.
http://speedof.me/show.php?img=170112075640-4017.png
Not bad for 40/10 connection, where the best I have seen it deliver is 37/9.25.
Impossible for 40/10, especially the up, but also down
Sounds like a blip from speedof.me
I've also had results higher than current sync in the past, which should very much be ignored as an error
-
I'm comparing like with like, in that I'm comparing speedof.me results with earlier results from the same tester.
I agree that speedof.me’s numbers are always higher than everyone else’s. Not that that is necessarily a bad thing, it could simply be that they are applying a different multiplication fudge factor to try and remove the overheads due to IP headers, or not, or to remove TCP and IP overheads both, or trying to remove the overheads of the entire DSL protocol stack because that is the kind of result they wish to portray so it can be compared with DSL line rates. It's not good when these testers don't say what it is that they are trying to report the speed of.
The highest downstream result that speedof.me reported is actually higher than the total of the Andrews and Arnold rate limiter setting values that clueless.aa.net.uk reports,
2503998+2548098+2503998 = 7556094
It's possible I suppose that the difference could be due to IP PDUs vs SDUs, that is the bits per second rating where IP headers are included or excluded as part of the total of bits counted.
-
I, too, have noticed that speedof.me is rather "generous" in its reporting and, as a consequence, only look at relative results from using that throughput tester. Which, I see, is exactly what Weaver has done. ;)
My current throughput tester of choice is: https://www.dslreports.com/speedtest?httpsok=1
-
What are the IP Profiles on your three lines at the moment?
-
These are the downstream figures now, reported by an AA / BTW modem status test
Line 1 2512 2848
Line 3 2556 2898
Line 4 2512 2848
I think the first number quoted is from BT and I'm assuming it is the IP PDU bitrate. The second number is I think the modem sync rate, again reported via BT and on to AA. These numbers are about as high as I ever remember seeing.
Looking again at the first numbers, the numbers quoted for AA's rate limiter earlier in this thread are indeed slightly lower.
Line 3 was horrendously unreliable yesterday, down for two hours from 18:00-ish and then again later.
-
I think the first number quoted is from BT and I'm assuming it is the IP PDU bitrate. The second number is I think the modem sync rate, again reported via BT and on to AA.
The ratio between the two supports that, according to Kitz on 21CN the IP profile will be 88.2% of the modem synch speed. What does that third line look like in terms of SNR and error rates?
-
Line 3 was showing the following this morning:
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2556kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=440kb/s LoopLoss=42dB SNR=6.6dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2898kb/s LoopLoss=64.9dB SNR=1.6dB ErrSec=12 HECErr=N/A Cells=0
I have since tried to reset the downstream target SNRM back to 6dB (was 3dB), and the latest numbers tonight are:
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2556kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=440kb/s LoopLoss=41.8dB SNR=6.5dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2851kb/s LoopLoss=64.7dB SNR=2.1dB ErrSec=0 HECErr=N/A Cells=0
-
Low noise margins in both of those especially the first. But the second shows a bigger drop from target. I notice the IP profile is the same, so in theory changing to 6dB shouldn't reduce your throughput.
-
I'm not sure how long it takes for the target SNRM change request to take effect? This was straight after I had hit the button.
-
Up to 4 hours.
-
This morning's tests, conducted all back-to-back included the definite all-time highest downstream speedof.me figure, at 7.77 Mbps
Time: 2017-01-21 05:56
down / up Mbps
7.72 / 0.94
7.77 / 0.99
7.74 / 1.06
7.67 / 1.00
7.72 / 0.96
This is with lines 3 and 4 set to a downstream target SNRM of 6dB now, and line 1 is on a 3dB target. Upstream target SNRM is 6dB for each.
Despite this the actual downstream SNRM figures are currently really low, lower than 3dB even for those on a 6dB target, and it seems possible that the SNRM drifts down fairly rapidly after initialisation time. Changing the target from 3dB up to 6dB doesn't really raise the medium-/long-term SNRM that much, it keeps it a bit above the really low 0.6-0.8dB region.
I have been using 3dB downstream target SNRM on all lines off and on for a year, occasionally going up to 6dB temporarily if there was suspected trouble. Until the autumn, I would say that the 3dB target was ok-ish, although it didn't provide much of a performance improvement. Over the last few months, during which there have been suspected and proven copper faults on the lines, stability has been less satisfactory than during the first half of the year, with a modem resynching about every six days very roughly.
Now as things are, I am not at all convinced that there is any performance benefit to be had from the use of 3dB for me. This could either be because
(i) too many uncorrected errors hurt TCP performance, or
(ii) the extra level of error correction overhead required is sapping throughput (seems less likely), or simply because
(iii) the downstream targets don't matter and the actual SNRM long-term ends up being about the same regardless of what the original target value was.
-
Now that it's stabilised do you have an idea of the difference that 3dB vs 6dB makes to the IP profile on the same line, for example Line 3? Also the line rate shown on the A&A portal. The upper limit for download speed will be the lower of the two. The other factor is going to be uncorrected errors that result in retries at the upper layers. Corrected errors (FECs) shouldn't affect throughput as they're corrected using data that's already been sent, I suppose possibly a high level of FECs might hit CPU on the modem if they're not handled on an ASIC.
-
The ip profile doesn't change after I have supposedly changed the downstream target SNRM, and that is after having allowed a long time - far more than the suggested 4 hours - for the target change to take effect. Note that the actual SNRM
Line 3, supposedly with 3dB target
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2556kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=440kb/s LoopLoss=42dB SNR=6.6dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2898kb/s LoopLoss=64.9dB SNR=1.6dB ErrSec=12 HECErr=N/A Cells=0
Line 3, supposedly with 6dB target
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2553kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=426kb/s LoopLoss=41.9dB SNR=6.4dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2894kb/s LoopLoss=64.9dB SNR=1.2dB ErrSec=1 HECErr=N/A Cells=0
-
Oh, and going back to something aesmith said earlier, what I meant about uncorrected errors was that the amount of error correction overhead in bits is a configurable parameter in ADSL - see G.992.3 §7.5 table of control parameters, and I don't know if modems might vary that as well depending on what the DSLAM says to them.
-
I'd forgotten you're on 21CN, does that support different levels or depths of interleaving? If so then that could affect the available rate.
FYI I just did a quick test to see the worst case effect from uncorrected errors by running a speed test from my desktop PC. Speed test returned 2.74meg which is 96% of the current A&A line rate of 2842156. That's with pretty much constant uncorrected error rate of 70 per minute, if my maths is right that's about 0.3% of full size IP frames being lost. Would be interesting to see a Wireshark of a speed test on an error free line, I suspect there'll be quite a few retransmits due to drops on the wider Internet side.
My 96% is a worst case because that's measured at a single PC without taking account of other traffic on the network here. To do a proper test I've found it effective to run multiple simultaneous downloads using something like ftp, then look at the total rate being received on the router.
-
Conveniently my line's been running error free for a bit, and running a couple of speed tests shows pretty much exactly the same speed. I think this confirms by belief that BT slowing a line down in response to high error rates is not for the good of the end user. Also suggests that the noticeable but low error rates on Weaver's line probably isn't hurting anything.
-
I strongly suspect that the following is what things should look like.
I later made a similar attempt on Line 1, that is, I tried to apply a change from downstream target SNRM = 3dB to 6dB, and I got the following - see below. As you see, the process kicked off a training period with the expected retrains, the sync rate reduced and the SNRM increased following a BT-forced resync, although the SNRM actually looks like it's been increased from basically zilch to 3dB, rather than from 3dB to 6dB. Really ought to wait for the required few days now though to see if it does go all the way up to something like 6dB.
I maybe need to power-cycle lines 3 and 4?
But it seems anyway that lines 3 and 4 are not being successfully controlled by BT due to who knows what reason, either something in AA or in BT's systems. It's not just in respect of SNRM, it's in respect of the lack of ability to either derive or set the FTR to the appropriate values when MSR is limited to max of 2272.
-- log for Line 1 (@a.1) --
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2512kb/s FTR=1817kb/s MSR=2272kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=537kb/s LoopLoss=41.8dB SNR=6.1dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2678kb/s LoopLoss=64.9dB SNR=2.9dB ErrSec=0 HECErr=N/A Cells=0 cwcc@a
20 Jan 11:42:03 Tweet: Line UP 2017-01-20 11:41:19 cwcc@a.1 01471822470 IV49 9BN OnLine AAISP
20 Jan 11:41:21 Tx rate (adjusted) 2503998 to 2354058 -Auto-
20 Jan 11:40:03 Tweet: Line DOWN 2017-01-20 11:39:55 cwcc@a.1 01471822470 IV49 9BN LostCarrier AAISP
20 Jan 11:39:08 20 Jan 11:39:53 Test SNR reset: RateBandDS=160-24384 InterleaveLevelDS=On TargetMarginDS=6dB RateBandUS=32-Uncapped InterleaveLevelUS=On TargetMarginUS=6dB:SNR Recalculation initiated which will enable the line to reach optimum speed, stabilization retrains can be expected over the next couple of days. cwcc@a
20 Jan 11:39:03 Update Update RateBandDS=160-24384.3dB->160-24384.6dB cwcc@a
17 Jan 09:01:17 Tweet: Line UP 2017-01-17 09:00:18 cwcc@a.1 01471822470 IV49 9BN OnLine AAISP
17 Jan 09:00:42 Tweet: Line DOWN 2017-01-17 09:00:17 cwcc@a.1 01471822470 IV49 9BN LostService AAISP
17 Jan 07:41:10 BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2512kb/s FTR=1817kb/s MSR=2272kb/s ServOpt=1 I/L=I
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=541kb/s LoopLoss=41.6dB SNR=5.8dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2848kb/s LoopLoss=64.9dB SNR=1.1dB ErrSec=0 HECErr=N/A Cells=0
-
I wonder if that SNR figure is in some way being misreported. If you forget the absolute values, things otherwise look as expected with the change resulting in a reduced synch speed and correspondingly reduced BRAS and A&A rates.
Regarding the FTR/MSR figures if it works the way mine did then I'd expect them to change shortly to 288/288 and then to the correct figures at the end of the training period. These won't affect throughput of course.
-
I expect the behaviour of the SNRM is related to the performance of the modems, which perhaps achieve high speeds at the expense of stability.
-
ejs is certainly correct - these DLink DSL-320B-Z1 are super-aggressive and there is a small price to be paid for this, not normally a problem though.
-
No matter what I do, the SNR seems to be too low. A bit low even compared to 3dB, never mind the fact that the target is now supposed to be 6dB. This is true for all three lines, although I'm pretty sure that the ten day training period hasn't completed yet. There have been log entries and resynchs that strongly suggest that the lines are indeed in the training period though.
-
I wouldn't worry about low reported noise margin unless either the error rate goes up or the line keeps dropping. From what I understand your "problem" line has been more stable on the 6dB target?
-
@aesmith: Line 1 is supposedly in the training period heading for 6dB, and indeed it has shown entries in the clueless logs that indicate that it is supposed to be doing it, yet the SNRM is still really low around 1dB. It shows little tiny flicks of packet loss a dozen times per day, very short periods each time, behaviour which the other lines are currently not exhibiting. So I'm not really worried about it, just monitoring it and wondering why nothing seems to really affect the actual SNRM achieved. The downstream sync rate went down very slightly, for something like 2550 to just under 2500 - I forget the exact numbers - after I supposedly adjusted the target. Maybe I do just have to forget about it until the ten day period is up, at least.
Even then, I don't know that I am going to actually do anything further about it, such as (trying) increasing the target to 9dB to see if that has any effect. I wouldn't want to lose any speed anyway as it is reliable enough currently, provided we don't get any more episodes such as the two-hour-long downtime with constant resynching that happened with line three a couple of weeks back.
These modems are just very aggressive and are perhaps just a bit waywardly so. I know there are modems that can apply a kind of offset target SNRM offset parameter, for want of anything like the correct term. Bet Bt really hate that. Maybe their defaults are just a little like that, but there does seem to be more to it, in that they do seem also to be unresponsive to pressure from BT+AA to (directly or indirectly) get them to change their behaviour.
-
Without access to any bitloading data, we don't know if the DSL-320B-Z1 supports monitored tones (the ability to increase the bits assigned to a tone that had previously been bitswapped down to zero bits). If the modem can't do that, then it's pretty much inevitable that the SNRM will tend to decrease and not recover.
-
yeah pretty much every modem I ever used on adsl never remapped bits to a tone once it reached zero.
So that meant after the first night time period when my high tones were battered down to zero bitloading, my lower tones had higher bitloading and of course I loss overall snrm for the remaining lifetime of the dsl session.
It really is an eye opener how much more stronger the signal is on short lines vs long lines.
If you look at a vdsl2 graph, the adsl frequencies only take up a small portion at the very left. On a 50db attenuated line (my old adsl line) then the strength of those tones was less than what I have on the far right of my vdsl line. Even with massive power cutback my vdsl line has higher bitloading then I could achieve with adsl on the same tones.
-
I didn't know that about zero bit-loaded tones. Very good to know, makes a lot of sense regarding cheap implementations. And indeed SNRM does tend to head downwards montonically, so this would explain a lot.
q1: Perhaps this has some implications for the best time of day at which to reboot modems?
q2: Perhaps modems need to be rebooted regularly in any case? (if you can manage it)
-
When and whether to reboot modems is down to what you deem most important on the line.
If stability is king then you want to reboot at night so you are syncing up during the time the line is at its weakest.
If raw performance is king then you do the opposite.
If you want the best of both worlds and dont mind downtime, then you could reboot when the sun comes up and again when it goes down every day.
The mystery of your snrm will probably be answered if you was plotting the historical behaviour of your lines.
-
I'm really just thinking out loud . . .
Weaver has three lines, thus three modems in office. There are 24 hours per day.
So how about an automated process that re-boots just one of the three modems every eight hours, in a cyclic sequence. Hence after the elapse of 24 hours, all three of the modems will have been re-booted. :-\
Of course I could just be caterwauling from the top of the pole, from which the drop-cable, that serves The Cattery, is connected.
-
But if the low SNR isn't causing a problem, why bother? If it continues to drop, day by day, then one night it will drop and reconnect of it's own accord. On the other hand for example my router seems to show reducing SNR for a day or so after a re-synch but then remains stable.
-
Indeed. :)
Just caterwauling by me.
-
The question, unresolved still, is how badly does the modem perform when the SNRM gets ridiculously low - should it perhaps give up sooner because it is delivering corrupt data all over the place? Rebooting modems would make a difference in that case.
-
Depends on why the SRNM is low. If it's low because of increased noise and/or reduced signal strength due to temperature, RF propagation etc then re-synch would be at a lower speed/higher margin. If it's low because of bit swapping dropping tones and not reclaiming, then resynch would probably be at the same speed but higher margin (this is what mine shows).
As for what harm it does, I believe modem should drop and attempt reconnection at some rate (maybe should be 0dB, but I've seen them go negative). Other than that it may cause higher error rates. Since you can't get real time stats from your modems at the moment, you could try grabbing a couple of snapshots from Clueless, one just over 15 minutes after re-synch and one at some later time when the margin's really low.
-
. . . (maybe should be 0dB, but I've seen them go negative).
I, likewise, have made such an observation with an HG612. It "held on" right down to -1.9 dB, only "letting go" at -2.0 dB.
-
I have seen Netgear DG834 modem/routers read a huge value which I presumed was a bug in the ascii decimal string conversion when the numbers go negative. It got fixed by a later update. They were famously happy to hang on at around zero dB.
This perhaps should be a configurable option in modems - minimum SNRM, plus hang on or give up: possibly conditional on actual recent error rate, and with an option to only resync if absolutely necessary or if below some SNRM threshold and / or above some recent error rate - as before - IF the link has been idle for x seconds recently, or within some time-window based on time of day. Those latter conditions would minimise the likely annoyance / impact of the downtime during reconnection.
-
line4
Does anyone know how long it takes BT to adjust their BRAS d/s rate on 21CN? When I was on 20CN, I used to refer to kitz' delay time table for guidance about the time - in the order of days rather than hours - it takes for BT to catch up following a d/s sync rate change, but I don't know what the timing is supposed to be like now I am on 21CN.
Most recent numbers for line 4 below. Showing the new absolutely all-time high sync rate of 2902, never seen anything in the 29xx range before.
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2319kb/s FTR=2278kb/s MSR=2848kb/s ServOpt=1 I/L=A
A SERVICE OPTION CHANGE ORDER IS IN PROGRESS ON THIS LINE
Up Sync=426kb/s LoopLoss=41.9dB SNR=5.9dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2902kb/s LoopLoss=65.1dB SNR=1.5dB ErrSec=0 HECErr=N/A Cells=0
The bras d/s rate of 2319 seems too low to me, it hasn't adjusted yet to the recent increase in d/s sync due to me going back to 3 dB d/s target SNRM at the end of the brief experiment of running on a supposed 6dB to see what difference that might make. (The 6dB experiment was unsuccessful. The modems just are not following the target and the actual SNRM doesn't in fact go up - it is low straight after a reboot, as far as I can see.)
The most recent quoted AA TX rate shown in the clueless log 2551626, which would mean that BTW is in control, not AA, one reason why the VoIP is possibly not going to work especially if you don't run at AA's suggested VoIP-friendly reduced rate of 95% (*). I suppose I will have to wait for BT to change their ideas on d/s rate and then they can report that to AA in turn. So, at the moment, I presume that a certain amount of traffic is crossing AA's network unnecessarily, only to get dropped by BT anyway.
--
(*) I use AA's phone service, but I couldn't get VoIP to work reliably, and nowadays can't get my Siemens Gigaset N300 VoIP box to work at all in any case, so I am using AA -> mobile phone inbound call redirection, which works brilliantly.
-
Just by the way I was searching for something else, and came across an older post from when I think you were on 20CN. If that's the case then it seems that the aggressive, low SNR behaviour of the D-Links applies on 21CN but not 20CN. You were reporting a lower sync speed as well, below 2272.
I'm on a TI DSLAM, and my target SNRM is the usual 6dB, with the DLinks, the SNRM doesn't tend to drop much below that.
-
Thing is, 3dB d/s SNRM target was not available on 20CN on my BTW line. Before I was upgraded to 21CN, the DSLAM was first upgraded, which produced a sizeable speed improvement, then I got ADSL2 which gave further improvement, and then I chose to switch from 6dB to 3dB.
The modems were well-behaved back then. Perhaps it is all down to this business of tones ending up at zero bits after a (short) period of change. And perhaps it is because I am starting off at only 3dB anyway that helps me get down to zero bits. Actually, more like, perhaps the fact that in ADSL2 single-bit tones are allowed, which they were not when I was on ADSL1, makes it very easy to get to zero bits. Perhaps I would be more stable under ADSL1.
But it's speed speed speed that I am after, and as long as stability is bearable I don't care too much as the three lines give me a lot more insurance compare with the usual situation. As long as I am engaged in normal non-performance-critical usage such as ordinary TCP, I don't even notice a line going down briefly. Mind you, on Sunday morning I lost a line for five minutes or so (rather too long?) and that reduction in total throughput completely stuffed up the Apple TV 4 box which was doing 'real time' live streaming, not a best-effort download. (Haven't worked out how to do downloads directly on to the Apple TV 4 itself. Can do Apple downloads to the iPad and send it to the Apple TV though.)
-
And now we have another all-time high result from speedof.me
d/s / u/s Mbps - server: London 2
7.81 / 0.91 * new d/s record
7.57 / 0.92
7.76 / 0.93
The BRAS rates are currently:
line 1: 2475k, line 3: 2521k, line 4: 2560k - total 7556.
The most recently reported AA Tx rates I can find are
line 1: 2466954, line 3: 2512828, line 4: 2551626 - total 7531408 (= ~99.7% of the BRAS total)
So I calculate that speedof.me is reading 3.7% higher than the AA Tx rate. So this is a small amount of exaggeration by speedof.me, especially since presumably the AA TX rate can't be including all the PPPoE+ethernet crap that is going between my modems and the BRAS, which means that my side of the link to the BRAS is handling more data than AA are seeing, not the other way around, and the total bytes a speedtester can count should be less, not more.
-
I've just realised that if speedof.me is to be believed at all, a big if, then that would indicate that the IP-bonding of the lines into one pipe is efficient in the downstream direction.
Upstream is not so good though, as my figures suggest that I have roughly a 20% performance loss somewhere, and that is even after taking out protocol overheads, if I believe in speedof.me rates and compare that with predictions based on upstream throughput derived from sync rate. I should be seeing around 1.2 Mbps but I get a speedof.me rating of 0.9 - 1.0.
-
The modems were well-behaved back then. Perhaps it is all down to this business of tones ending up at zero bits after a (short) period of change. And perhaps it is because I am starting off at only 3dB anyway that helps me get down to zero bits. Actually, more like, perhaps the fact that in ADSL2 single-bit tones are allowed, which they were not when I was on ADSL1, makes it very easy to get to zero bits. Perhaps I would be more stable under ADSL1.
Is the issue with zero bit tones that the router will never reuse them once they reach zero? If so that explains the way mine shows reduced SNR after the first evening, which isn't recovered until a re-synch. For reference see tones around 4 hours after re-synch, then after 8 hours then 48 hours later.
-
This phenomenon of ever decreasing snrm, is not good. Perhaps we need a much better modem. I never knew about this. It is an extremely important tick-list item on the shopping list for modems.
-
And aesmith will be (very slightly) less vulnerable to this badness than I am, because I may have some 1-bit tones on day zero, whereas he, being G.992.1 iirc, will have a minimum of 2, so less close to zero.
-
Weaver at least its temporary on adsl :) on vdsl crosstalk can be permanent knock on affect of snrm. :p
-
And aesmith will be (very slightly) less vulnerable to this badness than I am, because I may have some 1-bit tones on day zero, whereas he, being G.992.1 iirc, will have a minimum of 2, so less close to zero.
I don't think that makes any difference. If an ADSL1 2-bit tone no longer has sufficient SNR, it gets bitswapped to zero, same as when an ADSL2 1-bit tone no longer has sufficient SNR.
-
Weaver at least its temporary on adsl :) on vdsl crosstalk can be permanent knock on affect of snrm. :p
My ADSL2 line seems to be suffering from about 2dB SNRM worth of crosstalk, which has been pretty much permanent apart from a few blips consistent with a modem being rebooted.
-
Out of interest how do you know it's crosstalk, as opposed to external interference or other factors?
-
I don't really know, but it appears consistent with a noise source of constant strength that's on almost continuously, apart from a few upward spikes of SNRM which are consistent with a modem re-connecting or rebooting. Occasionally it's been off for half an hour or so. The SNR per tone graph doesn't show any new interference on any particular tones, just a general reduction of SNR across the whole range.
I might have spotted a previously unseen BTHub3 from scanning the wifi at the time, but this isn't terribly conclusive, and I don't seem to have made any note of the exact wireless SSID.
It started on 22 July 2016, 10 January 2017 was the most recent time I've seen the SNRM spike upwards.
-
A new level of madness recently, 8.11 Mbps downstream on 2017-12-14 and 1.54 Mbps upstream on 2017-12-17. Those are both speedof.me test figures, using the London “CoreIx” server, which is the server that gives the highest downstream figures for me.
Perhaps due to snow lying on those dates. The snow has gone now and performance figures decreased vastly and downstream sync rates reduced slightly, needed in order to maintain stability as actual d/s SNRMs we're far too low (<1dB) meaning observed packet loss occasionally. I'm assuming that the snow is correlated. The performance figures at the start of the monthndid not hit that extreme high level. possibly there was no snow at the beginning of december, unfortunately I do not remember.
Perhaps snow means isolation from distant RF noise sources? And perhaps it acts to change the electromagnetic environment around the bundle, producing some kind of frequency response shaping. (No idea what I'm talking about, Theoretical Physics first degree fails me.) If the latter is true it might be that that counts as a noise filter in the crosstalk too, blocking crosstalk from disturbers on short lines who can use the higher tones. Both could be true.
-
I know when temperatures get really low (around -270oC) strange effects kick in and materials become super conductors.
It's not that cold in Skye is it? :P
-
A new level of madness recently, 8.11 Mbps downstream on 2017-12-14 and 1.54 Mbps upstream on 2017-12-17.
That certainly exceeds the capabilities of my circuit. :o
Perhaps due to snow lying on those dates.
Without any other evidence, i.e. other residents in Heasta having gone away and switched off their equipment, I can accept that the snow was acting in a beneficial way.
Perhaps snow means isolation from distant RF noise sources?
I thought we had previously agreed that your isolated location was already playing its part in ensuring you have minimal RF ingress?
-
@Burakkucat - Indeed, I do think my isolated location and first-in-the-village situation should help with my clean low noise environment. I was thinking of things like radio stations, when I used the term "distant".
The amazing high value was only sustained for a couple of days. But on the 14th, many tests were done and all gave spectacularly high d/s or u/s throughput figures. Comparing the 14th with the 12th Dec, downstream IP throughout went up by ~400k as measured repeatedly using two completely different speed testers. So it was not just a glitch in speedof.me.
I took half a dozen measurements in each case, recorded all the numbers, and took the arithmetic mean and the max. (I would have thought that geometric means would be more sensible, but I actually want the bias from the high values.) I'm much more interested in the max as I believe that is reliable, because alien local or remote competing traffic or slowness within the remote end test server itself can reduce the figures, but external disturbances can't improve results. The very lowest outlier results, if any, in each group were discarded, assumed to be a failure due to the network not being quiet. I checked for alien traffic going through the router if any bad results were consistently seen.
-
Since I have three modems on the go, one of them dropping the link (for ~80-120 s typically) isn't a problem at all because the AA routers and my Firebrick at my end switch the load over to the other working links. I never even notice one dropping and resynching, apart from the notification tweets and SMS messages that I get from AA. I am fine with a few drops themselves per week because of my chosen low downstream target SNRM of <3dB. However periods of packet loss because the SNRM has dropped way too low aren't good.
There doesn't seem to be a “give up and resync if SNRM goes below x" option as far as I can see. I wonder if anyone has seen such a thing with other modems? Modem designers perhaps wouldn't want this, as they might regard it as reducing stability / reliability because the modem wouldn't “hang on in there” bravely regardless, something many customers might really want badly. But in my case my needs are different, I don't care much and if there is going to be packet loss when the SNRM is low then I just want to give up before that. (Reminds me a bit of modern intelligent magnetic hard disks with CPUs in them and internal bad sector hiding software tricks, which I imagine you do not want if in a RAID array.)
I really do want it all, bitswap [of course!], monitored tones please and definitely SRA from BT's MSAN/DSLAMs now I've got ADSL2, seeing the modem says it supports SRA.
I would be a bit surprised if these devices fail to do bitswap when they have gone to all the trouble of (supposedly) writing the code for SRA. I mean this implies that they aren't quite so mean and stingy with their software development efforts, so not bothering to get bitswap done wouldn't seem likely.
I wonder if they simply haven't done bitswap correctly?
-
I think most DSL modems have always had an option to drop the connection once the SNRM hits a minimum value, but the minimum value always must be specified by the DSLAM, it's usually referred to as something like "CO min margin". It's one of those features that always been there, but not widely used.
-
At the moment, I can only come up with one suggestion . . .
Perhaps you could install a time-switch for each modem and once every 24 hours, during a defined time window, power-cycle each device in turn. :-\
-
weaver my suggestion is to make sure you sync at adsl2 instead of adsl2+, adsl2+ will likely be slower on your lines.
-
I'm pretty sure @Weaver has already done that.
I think the ADSL2/2+ setting makes no difference on the newer exchange equipment anyway, I think it's actually that the earliest BT ADSL2+ exchange hardware does ADSL2+ poorly, especially on long lines, rather than anything about the ADSL2+ specification itself.
-
ejs - tis a 2015 Msan. Modems are indeed themselves set to ADSL2-only rather than "auto"-mode, thanks to Burakkucat's tip way back when.
@burakkucat - have thought of the switch thing, started looking round for suitable hardware.
I looked into the possibilities of remote-contrling a switch. For some reason, did not think about just a switch with a fixed time setting, not remote controlled.
AA now have a facility where you can get info and issue commands using a machine-to-machine http-based protocol, called CHAOS. I looked into that, no joy currently - what I need isn't yet documented.
I can remotely force a resynch now by misusing manual commands to AA's control / admin / info web server 'clueless'. Such a dirty trick saves me from needing to obtain help manually power-cycling modems in the office. I haven't yet worked out how to automate that though. It would be very messy before they add explicit support for such in the CHAOS protocol.
-
now the snow is back and I will retest.
So I need to re-test. Am assuming there is some non-zero snow depth.
Thinking about reprogramming a modem to the wrong bitswap setting to see what happens.
Warned RevK that I might have unintentionally told him to do evil before. <span lang="gd">Mas breug bhuam-sa, bu bhreug chugam-sa."</span> once again
-
Weaver, what's your EE reception like? Seem to remember you had EE as a backup.
https://www.thinkbroadband.com/news/7944-ee-launches-4gee-home-antenna-as-potential-uso-solution
-
EE is fantastically good, and Three is good too. Line of sight direct to basestation for all services across the valley. I get 40Mbps EE near the window and I could place an 3G/LTE Dongle in the window connected to the Firebrick router which has a dedicated usb interface just for the purpose. However the costs are ridiculous; I racked up a £50 bill in one day with Three, just with one machine going. So it's completely unaffordable. And it's only fast because no locals can afford to use it, being a shared service.
I'd rather stick with the slower DSL and have IPv6 (no IPv6 with AA over AQL over Three for some mad reason) and not be bankrupted. I can afford to use AA's 'units' DSL tariff very heavily if I do so overnight in the cheap rate 0200-0600 time band for movie downloads instead of live streaming.
-
I suppose it depends on how much data you use, but one offer mentioned in the article was 200GB a month for £60, I thought you were paying around double that for your three AA lines.