Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

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.

[Weaver]

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

[Weaver]

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
-------------------

[Weaver]

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.)

[Weaver]

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.)

[aesmith]

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.

[NEXUS2345]

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).

[William Grimsley]

You're not uploading to MDWS!

[Weaver]

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.

[Weaver]

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.

[Weaver]

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.

[ejs]

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).

[Weaver]

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?

[ejs]

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".

[Weaver]

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.