exchange negotiates deliberately unstable 3dB target SNR from today- why ?

[#1]

@azagoth
no - the info you posted does not indicate why you only get 6.5M out of a possible 11M or 12M - you should post everything that your data source lists ( to a new thread)
The info you need to look for is called RCO - relative channel occupancy - which can be a lot less than the sync speed, depending upon how much of your bandwidth is being taken by error protection bits imposed because your telephone line is sub-standard.
[edit: I'm wrong - RCO is not the percentage measure of interleaving overhead and you appear not to have interleave - sorry  :-\]

[#2]

My line just did this today hmmm
stable so far anyways not really happy about interleaving being put on though.

[#3]

@epyon
I'd keep an eagle eye on it. Are you seeing Reed-Solomon uncorrectables at 3dB interleaved ?

[#4]

Its been clunky when using PPPOA i've switched to PPPOE and everything seems ok now i'll leave it a few days and see how i get on.

[#5]

Hi disfroot,
Seems the instability from Thursday-Saturday (see graph) has caused your line to be banded. That's why you can't sync any higher than 2272Kbps at the moment. If you plug into the test socket I can see if that can be removed.
Jojo

[#6]

@Joanne
All of those disconnects you show were caused by me deliberately re-training the line after discovering it was crippled at 2M  and, on Sat pm, carrying out the tests required by the fault reporter !!! The graph shows no failed connections, only session starts and stops.
The 'banding' must have occurred earlier ?
I will raise a slow speed fault report.

[#7]

Hi disfroot,
By all means raise a fault, but like I said if you plug into the test socket I can get the banding lifted.
Jojo

[#8]

@Joanne
I'm sorry - I don't understand what's going on here. In particular, I don't see the connection between having 'banding' lifted and me plugging directly into the MJU.  
When I filed a fault report, the troubleshooter asked me to plug my microfilter directly into the test socket. That made no difference to my line stats - indicating strongly that whether I am plugged into the test socket or not is not a factor. In fact, the only difference in my house wiring between being plugged into the test socket and having the MJU faceplate attached is just the MJU faceplate connector - I have no house wiring attached to the rear IDC connections of the faceplate. All my house analogue telephones are beyond the first microfilter.
Why doesn't the fault team lift the 'banding' as part of their investigative process ? And if you lift it, won't you confuse them ?
and I was advised to raise a fault report, as clearly this 'banding' is an unreasonable restriction placed as a result of a fault.

[#9]

@Joanne
OK - I am now permanently plugged into the test socket behind the MJU faceplate. Please take whatever action necessary to increase my broadband speed back to my previous ADSL2+ performance levels (17Mbps profile or better)
Thanks.
ps - why doesn't a fault report automatically get filed when BT place a line onto this inferior sub-ADSL1 'banded profile' ? At the very least, a warning e-mail to the customer that their line has performance problems would be reasonable ?
pps - could you please post the graph data for the 10 days prior to the period you posted ?

[#10]

HI disfroot,
I will look into getting that lifted. Once I have then please leave it in the test socket. If we do this we can get a better idea of whether it's something internal or external.
Jojo

[#11]

@Joanne
I'm now connecting at 15323 11-12dB SNR, but the existing problem of significant error rates on the line remains unfixed.
Here are my modem stats for this afternoon and evening
---
[tt]
BusyBox v1.00 (2006.09.20-01:51+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
# adslctl info --show
adslctl: ADSL driver and PHY status
Status: Showtime  Channel: FAST, Upstream rate = 1224 Kbps, Downstream rate = 15323 Kbps
Link Power State: L0
Mode:                  ADSL2+
Channel:                Fast
Trellis:                ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):      10.8            6.3
Attn(dB):      23.0            11.1
Pwr(dBm):      0.0            12.1
Max(Kbps):      18660          1228
Rate (Kbps):    15323          1224
                        G.dmt framing
K:              239(0)          57
R:              16              6
S:              1              4
😧              64              4
                        ADSL2 framing
MSGc:          59              10
B:              238            56
M:              1              4
T:              2              3
R:              16              6
S:              0.4980          5.9240
L:              4096            316
😧              64              4
                        Counters
SF:            1960492        1960490
SFErr:          6              0
RS:            254863976              33328330
RSCorr:        4983            0
RSUnCorr:      57              0
HEC:            6              0
OCD:            0              0
LCD:            0              0
Total Cells:    1146919359              807204
Data Cells:    793939          29207
Drop Cells:    0
Bit Errors:    0              0
ES:            6              0
SES:            0              0
UAS:            91              0
#[/tt]
---
I'm guessing that I'll be going round the same loop again as the broken DLM logic gradually edges me nearer to a sub-ADSL1 banded profile like before. As your faults people have also interpreted the graph that you posted as temporary  'line instability' - they think that it might just go away on its own.  I hope I don't have to keep posting here, frankly. I'd like it fixed instead.

[#12]

There isn't anything there that is a high error count.
There is no explicit "uptime" figure, but the SF stats (superframes) show 1960492, and at 59 per second, this represents just over 9 hours.
In that time, you've had 6 superframes with errors, all of which are counted as HEC errors. There were 6 ES (Errored seconds), which means all 6 errors came very spread out - suggesting that the interference was not a single impulse.
Conversely, your interleaving is working. There were 254863976 RS (Reed Solomon) chunks, of which 4983 were detected to have a fault, but the FEC (Forward Error Correction) process fixed them. There were 57 RS chunks that could not be corrected by FEC, and these 57 will have led to the 6 HEC errors.
Less than 1 error per hour is trivial - I get 8-10 an hour on a rock-solid line, although that is with interleaving turned off (so there is no FEC process happening).
In fact, the only figure that looks out of place is the 91 UAS (Unavailable Seconds). This means that your line has taken 91 seconds to synchronise (or re-synchronise). That is a lot, given the low number of faults shown in the rest of the stats.

[#13]

@WWWombat
Thanks for a superb post ! I've learned loads from it - one of the best ADSL-explanatory posts I've seen, in fact.
My worry about the non-zero number of uncorrectable RS errors is based on my ADSL1 experience. I had an 8128/448 line and the only time I ever saw uncorrectable RS errors in my stats was when there was an obvious voice fault on the line. How did you calculate 59 superframes per second, btw ?
At what error level will the DLM seek either to raise or lower the target downstream SNR, though ? Is my current error level going to mean the DLM stops its pernicious fiddling ? All this info is still missing - or at least, I haven't seen any posts that detail the make and model of DSLAM that BT uses and whether they have overlaid their own DLM logic on it or are using the algorithms that come with the kit.

[#14]

Sorry, I was away at the weekend...
ADSL1 works nominally on 4000 frames per second, in sending the various streams of data (whether DSL header/framing, fast-path, or interleaved user data). Within those frames, the interleaved data is sent as small chunks encoded with RS - but I've never really worked out the rate at which those happen.
However, the ADSL frames are then grouped into a "superframe" structure - with 68 frames carrying data, and 1 frame carrying synchronisation data, so that the receiver can work out the way the frames have been structured. I think the frame rate is actually adjusted to squeeze in that extra sync frame, so to get 4000 frames/sec of user data, the line runs at (69/68*4000)=4058ish frames per second.
CRC data is calculated on a superframe, and then sent (in 8 bits) as  part of the 1st frame of the next superframe. This means that CRC failures can only come every 68th (user) frame from the 4000 (user) frames/sec - or 58.8 CRC errors per second.
More information around pages 7 and 8 here: http://www.iol.unh.edu/services/testing/dsl/training/ADSL_Tutorial.pdf, but it is a very techie document.
I don't know about HEC errors directly, although they seem to be CRC checks on the ATM cell headers. However, my experience (on my Netgear DG834GT) is that the HEC error count seems to be a subset of CRC error count, and never appears alone; I've so far assumed that they therefore follow the same rules on timing... but cannot really be sure.
As to the error-level needed to cause changes in the  SNR targets, I don't know. It has only happened to me once - and the time the SNR was changed occurred rather later than the errors actually happened: I had 4 significant bursts of CRC+HEC errors over a day (11PM, 3AM, 10AM and 3PM, if I recall), and the line resynced around 5PM when there were no problems. I don't know the actual number of errors in the spikes, as my statistical graphs now average those 2 days over the entire 24 hour period, rather than keeping the counts related to each 15-minute period. They show the average about 500 errors - suggesting that the spikes were around 10,000 errors in a 30 minute period.
I've attached 2 graphs that give an idea of the scale of "normal" and "abnormal"...
You can see some of the smaller "mini peaks" on the 2nd graph. The one earlier in May was about 1600 errors in a half-hour period, and the spike in April was 3 bursts (150 over 2 hours at 8AM, 600 over 2 hours at 10AM and 900 over 2 hours at 6PM). Neither of those caused a twitch in DLM - but the spikes in February did trigger it.
I think we have some ideas that a number of *resyncs* in a short period can trigger DLM, but I haven't seen anyone yet show how *errors* (without resyncs) can trigger DLM.

[#15]

FWIW, my line seems to hold synch as long as the CRC errors don't exceed about 10,000 per day. If it gets beyond that then the DLM seems to trigger a resynch at a lower speed. I haven't a clue what the time distribution of the errors is though.