Kitz Forum
Broadband Related => ADSL Issues => Topic started by: Weaver on August 03, 2016, 03:46:49 AM
-
As I mentioned earlier in the year, I've been trying out the 21CN 3dB downstream target SNRM that my ISP - Andrews and Arnold - offers to BT line users. I have three modems using ADSL2 on very slow lines ( ~2.5 Mbps downstream sync rate, 66dB downstream attn.).
I was rightly warned at the time about the perils of choosing a 3 dB margin, so I went into this with my eyes open, regarding it as a trial and ready to revert back to 6dB target SNRMs if needed. So the question is, how do we categorise the performance at 3 dB? As a success or a failure?
After a day or so, the downstream SNRM nowadays droops from 3 dB to something like ~0.6 dB. It used to be rather better, around, say, something like ~1.5 dB.
I suspect the modems resync every few days at the moment. I'm basing this on the uptime figures published by the AAISP clueless.aa.net.uk server, which I think may possibly be based on PPP disconnects, not necessarily on resyncs observed by the MSAN/DSLAM at the Broadford exchange. Because of the nature of the reporting, I could easily miss a disconnect/reconnect event, since on the latest disconnect and reconnect time is reported, so I check every day or so, hopefully I remember to.
-
see also earlier thread on experiences with 3 dB, its significance and its reliability:
http://forum.kitz.co.uk/index.php/topic,16702.msg307972.html#msg307972
-
This is a record of the (suspected) resync events, which I think may be derived from PPP disconnect/reconnect event pairs. I got the data from daily (hopefully) checks on AAISP’s clueless.aa.net.uk control panel/stats/log server.
--
DSL log
------
reconnect: line 1 :-
2016-08-01T19:32:11 UTC (down for 1s !!)
2016-07-31T20:24:57 UTC (down for 12s)
2016-07-26T13:46:42 UTC (down for 10s)
2016-07-16T21:23:25 (down for 10s)
2016-07-15T23:30:38 (down for 11s)
--
reconnect: line 3 :-
2016-08-01T19:32:11 UTC (down for 1s !!)
2016-07-30T23:48:09 UTC (down for 169s !!)
2016-07-30T01:32:14 UTC (down for 9s)
2016-07-26T02:11:54 UTC (down for 11s)
2016-07-16T13:48:05 (down for 1s !!)
2016-07-15T16:26:18 (down for 86s !!)
--
reconnect: line 4 :-
2016-08-01T19:32:11 UTC (down for 1s !!)
2016-07-24T20:06:13 UTC (down for 11s)
2016-07-14T20:47:48 (down for 16s)
------
--
2016-07-16 :: up sync line 1 : 509k
2016-07-16 :: up sync line 3 : 406k
2016-07-16 :: up sync line 4 : 389k
--
--- line 1: --------
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2296Kb/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=509Kb/s LoopLoss=42.8dB SNR=6.2dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2603Kb/s LoopLoss=65.7dB SNR=1.5dB ErrSec=0 HECErr=N/A Cells=0
--- line 3: --------
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2330Kb/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=406Kb/s LoopLoss=43.1dB SNR=6.1dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2627Kb/s LoopLoss=66.2dB SNR=1.2dB ErrSec=1 HECErr=N/A Cells=0
--- line 4: --------
2016-07-16 ::
Today 13:11:33
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2292Kb/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=389Kb/s LoopLoss=43.8dB SNR=6.7dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2599Kb/s LoopLoss=66.9dB SNR=2dB ErrSec=0 HECErr=N/A Cells=0
-------------------
-
The current SNRM figures, as opposed to those given above from a couple of weeks back, are rather worse, and the numbers of errored seconds are a bit higher.
* I've recently changed line 3 (confusingly they are numbered 1, 3, 4 by AA) back to be set at 6 dB downstream target SNRM. Interestingly this only subtracted ~80kbps from the sync rate and the actual SNRM soon settled downwards from 6 dB to be only 1 or 2 dB higher than it had been when in the 3 dB target state. I did this because it seemed to be struggling, with a greater number of errored secs, and also because it would make an interesting side-by-side p comparison.
* Line 3 is currently still in the training period. Does this mean that DLM will force some resyncs?
(If so, I’ll be getting some misleading events polluting the log I've been building up.)
-
Btw, I have no idea why I can't see the number of HEC errors any more. (The reporting system perhaps started behaving like that when I was upgraded to 21CN / ADSL2+ at the end of 2015, I can't remember when I first lost those count values.)
-
Errored seconds seem low enough on those snapshots. Did you ever get clarification as to whether those counts are for the current 15 minute period, or for the last 15 minutes? Neither Plusnet nor A&A seemed to be sure.
So the question is, how do we categorise the performance at 3 dB? As a success or a failure?
I would see it as a success if the following were achieved .. (1) increased throughput (2) sufficient stability not to annoy you and (3) low enough error rates that DLM doesn't knock you back to 6dB or worse. So on what you've posted so far, I'd say success.
-
My line for some reason has been syncing at 3dB SNR for months now with Zen. I haven't seen any major issues apart from a few downstream CRCs a day (it sounds bad but it doesn't have any major effect). Burrakucat noticed this the other day on my thread, and you can see it on MDWS (username NEXUS2345).
-
You're not uploading to MDWS!
-
Re MDWS I don't have the technology (yet) to export data from three modems on the far side of this particular router - see earlier threads on this subject.
-
Re error counts. I suspect the AA error counts are since latest reconnection. This is far from certain, I would need to correlate this with the timings of the latest supposed resync events.
-
Well, if I wait fifteen mins and see if an error count goes down to zero, or at any rate, decreases, then I'll know.
-
Is it possible for you to obtain graphs of the RRT (Reactive Repair Tool) Historic data, as collected by the DLM? In theory it should provide similar data as running a stats monitoring program would (slightly less fine grained, because the data is only collected as 15 minute intervals).
-
re RRT
@ejs - I can certainly ask AA support if they can grab this data for me.
btw, does anyone have a reference for RRT they could point me at?
-
From https://www.btwholesale.com/pages/static/help-and-support/orders-and-faults.htm
Under "Broadband Faults, Performance Issues & Troubleshooting"
There's the "Introduction to Self Service Repair Tool" and "Reactive Repair Tool Best Practice User Guide".
-
aesmith wrote:
> I would see it as a success if the following were achieved .. (1) increased throughput (2) sufficient stability not to annoy you and (3) low enough error rates that DLM doesn't knock you back to 6dB or worse.
With regard to point (1), the extra throughput is possibly surprisingly small. The downstream sync rate on line 3 seems to be only ~ 80kbps lower (out of ~2500k) on a 6 dB target SNRM, as it is now, compared to when it was on 3 dB a couple of days ago. Bear in mind that it is still not yet out of training period, if that makes any difference.
As for point (2) stability is I think good enough, even if not perfect. It may be that having three modems helps paper over the cracks? Is that possible?
The thing is, I don't know if AA’s load sharing can detect a dropped connection fast enough to take a line out of the set and pass the load over to the other two pipes quickly enough, before a lot of packets are dropped, to make things fairly seamless. The thing is, the only time I would ever care would be with a non-TCP protocol (or SCTP etc, protocols with retransmission anyway). There will be some dropped packets, so that would perhaps affect streaming video? eg Netflix? (Or does the likes of Amazon / Netflix use TCP or SCTP now?) Or VoIP?
And point (3) is a definite "no" - DLM certainly isn't intervening. So in fact DLM is a learned judge giving a thumbs up?
So given that I doubt I'm getting much benefit, but possibly not taking too much harm either, the stay/revert decision depends on (2), and on what the real noticeable effects of a resync are on the likes of VoIP and Netflix in terms of user-perceived errors as opposed to things that can be corrected for in the protocols.
-
In regards to me not uploading to MDWS as of current, I am currently away on holiday and so the only computer I have set up to upload is currently offline, as well as my HG612 unplugged in case of a lightning strike...
-
Snapshot of the three lines on 3 Aug
=== Line 1: ===
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2232Kb/s FTR=1817Kb/s MSR=2272Kb/s ServOpt=1 I/L=I
Up Sync=515Kb/s LoopLoss=42.9dB SNR=5.8dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2531Kb/s LoopLoss=66.2dB SNR=1.7dB ErrSec=0 HECErr=N/A Cells=0
===
=== Line 3: ===
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2223Kb/s FTR=1817Kb/s MSR=2272Kb/s ServOpt=1 I/L=I
Up Sync=402Kb/s LoopLoss=43.1dB SNR=5.8dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2521Kb/s LoopLoss=66.3dB SNR=2.5dB ErrSec=1 HECErr=N/A Cells=0
===
=== Line 4: ===
BT Test xDSL Status Check:Pass Standalone sub test passed successfully.Pass OK. Circuit In Sync
BRAS=2364Kb/s FTR=2278Kb/s MSR=2848Kb/s ServOpt=1 I/L=I
Up Sync=409Kb/s LoopLoss=43.5dB SNR=5.5dB ErrSec=0 HECErr=0 Cells=0
Down Sync=2681Kb/s LoopLoss=66.6dB SNR=1.5dB ErrSec=0 HECErr=N/A Cells=0
===
-
I wonder why your snapshots don't include ILQ. I'm assuming these are from clueless via the "Sync Status" option. The equivalent from my line includes a line which might read "THIS LINE IS STABLE AND WELL WITHIN ERROR/RETRAIN LIMITS FOR THE CHOSEN SERVICE OPTION (ILQ=GREEN)" if all is going well.
By the way are those real MSR/FTR figures for lines 1 and 3?
-
I've never seen the ILQ thing in clueless. How odd.
The MSR / FTR figures are just as clueless reports them, and have been nonsensical for an age. I would rather like to get the FTRs fixed.
The >2800 downstream sync rate for line four would be from last December I suspect.
-
If you think the sync rates might improve in cooler weather, then it might be an idea to get the two MSR/FTRs reset at that time. You should be able to initiate that from the "SNR Reset" button on Clueless, at least I have done so on my 20CN line.
-
I used the SNR reset feature, on a couple of occasions since last December, but it seemed to make no difference to the MSR/FTR issue. It simply set the target SNRM, as it should, but did no more than that.
-
I wonder how you do it on 21CN then. For my line the only option is that reset, which sets it back to 6dB/Fast and restarts the learning process. When I selected the option it logged the following ...
"Test SNR reset::SNR reset initiated which will enable the line to reach optimum performance, service interruption may be experienced during this period."
Just a random thought, I wonder if on 21CN it only relearns if you reset back to the default 6dB?
-
The thing is, a few days ago, I did an SNR reset and set line 3 back to 6 dB downstream target SNRM. And that hasn't fixed the MSR / FTR, so it remains a mystery. One for AA staff I think.
If some bad line fault were to develop, I (or is it "AA and I"?) would not get the "benefit" of a quotable FTR-breach at the correct level.
It's very weird - I don't understand why there's the difference between lines 3 and 4. Line 4 behaved as normal and increased its MSR when I converted to 21CN / ADSL2+ last December. Note how the (rung) value 2272 (from the 20CN days) has just got jammed into the MSR fields for lines 1 and 3, and has, it seems, become detached from the updating process which would normally be expected to overwrite it.
-
I guess it would be a question for A&A. Not that it helps but after I did the SNR reset here the MSR/FTR changed from the preexisting 2272/1817 figures, to 288/288 which remained until the end of the 10 days.