Print

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

[Weaver]

I think there’s a slight trend upwards:


Have forced a resync twice to keep the error rate down. This has resulted in a further downstream sync rate reduction, to 2.310 Mbps, from an original 2.9 Mbps; upstream unchanged at 573 kbps

[Weaver]

After I forced the target downstream SNR up to 6dB, in order to control the rising error rate, it only remained like that for a few days before  DLM pushed it back down to 3dB at around 06:30 this morning. The HCD and the downstream sync rate remained stable apart from this DLM event. The downstream sync rate is now around 2.2 Mbps @3dB.

[Weaver]

The deterioration continues slowly. The HCD hollow is now about 8dB deep[!]. Yesterday I checked the stats and the CRC error rate was ~2k per hr. I decided this was completely silly and increased the downstream target SNRM from 3dB to 9dB. This knocked the downstream synch rate right down to 1.191 Mbps, as is to be expected. When all is well it’s 2.9 Mbps downstream at 3dB with no errors.

My thinking is to definitely let it get ridiculously bad before OR are called in, and this is what I proposed to AA, asking them to keep an eye on it, to check it regularly and to decide when they think it’s bad enough to give an OR engineer a really, really good chance of finding the fault. It just means living with a rubbish line for longer than is perhaps necessary.

Looking at the framing parameters, I can’t seem to get any downstream interleaving, downstream D=1. I have it set to downstream interleaving=ON in clueless.aa.net.uk, but that doesn’t seem to be working. Don’t understand what’s going on. A few questions:

• I don’t know how to tell how beneficial this would be - can’t see what type of noise I’m getting. Surely more interleaving is never a bad thing, if you don’t care much about latency.
• There’s plenty of interleaving on the upstream, D=8.
• Perhaps this is something to do with the presence of downstream L2ReTx in the form of PhyR? Maybe the modem just decides it doesn’t need to have interleave if it can do retransmissions, and if so, it then overrides any instructions from outskde? Does that make sense or seem doable?
• In FTTC, what happens about interleave depth D vs G.INP on/off?

[Weaver]

Deterioration continues. I’ve now forced the downstream target SNRM up to 15dB which has brought the downstream sync rate down to 611kbps. This is the best I can do now, and any worse and I’ll have to turn the modem off in order to prevent it from polluting the whole bonded link with CRC errors. It had also got to the stage where it was dropping sync sometimes (at 12dB downstream). I’ve updated AA and asked them to decide if now is the time to finally give up and call OR in, given that we’re waiting until the fault is likely to be successfully located and properly fixed, because it’s really really bad and shows up.

[burakkucat]

A target SNRM of 15 dB is incredibly severe and the fault seems to be as hard as it can be (other than a disconnection). 

[Weaver]

Indeed. It has now completely failed to synch and the link has been down for many hours. I emailed AA at the weekend so they will get it on Tuesday morning.

[Weaver]

AA has booked an OR engineer for Thursday. Here are some pictures for those who don’t frighten easily:

[Weaver]

Full stats sampled on Wednesday afternoon. I don’t quite know what has been going on here; Things have improved a lot in the past hour or so. The ES have dropped to 0 at last. This is presumably because of the high RS error correction combined with the recent arrival of a small amount of interleaving, D=2, not enough but finally better than zero. The payload of a downstream RS FEC frame is small at only 6*2=12 bytes (plus one sync byte), with R=16 bytes of RS CRC appended. I’m wondering if it’s possible that this was caused by the intervention of BT DLM. I don’t know if BT DLM is even turned on for this line. Can BT DLM be turned off on a BT 21CN ADSL2 line? I could ask AA.

If it stays like this then at least it’s usable, reliable, albeit at this painful downstream speed of ~10% of what it should be. An interesting investigation into a sick line at its very slowest.

Code: [Select]

xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 439 Kbps, Downstream rate = 1324 Kbps
Bearer: 0, Upstream rate = 522 Kbps, Downstream rate = 288 Kbps

Link Power State: L0
Mode: ADSL2 Annex A
TPS-TC: ATM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 10.5 6.0
Attn(dB): 67.5 41.5
Pwr(dBm): 16.7 12.3

ADSL2 framing
Bearer 0
MSGc: 91 11
B: 6 62
M: 2 1
T: 1 1
R: 16 12
S: 1.2903 3.7975
L: 186 158
D: 2 8

Counters
Bearer 0
SF: 561802 574176
SFErr: 12443 0
RS: 27247410 1166457
RSCorr: 414017 858
RSUnCorr: 37103 0

ReXmt: 540802 0
ReXmtCorr: 527585 0
ReXmtUnCorr: 37235 0

Bearer 0
HEC: 6510 0
OCD: 0 0
LCD: 0 0
Total Cells: 6169219 11410815
Data Cells: 300046 297485
Drop Cells: 0
Bit Errors: 881256 0

ES: 15505 12
SES: 4771 3
UAS: 154729 151302
AS: 9266

Bearer 0
INP: 28.00 2.00
INPRein: 0.00 0.00
delay: 8 8
PER: 15.64 16.13
OR: 49.60 8.42
AgR: 321.14 528.81

Bitswap: 13/13 6/6

Total time = 2 days 5 hours 43 min 59 sec
FEC: 1090244 1276
CRC: 67862 0
ES: 15505 12
SES: 4771 3
UAS: 154729 151302
LOS: 298 0
LOF: 888 0
LOM: 3 0
Latest 15 minutes time = 13 min 59 sec
FEC: 2171 315
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 2642 51
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 5 hours 43 min 59 sec
FEC: 789678 978
CRC: 39210 0
ES: 5857 3
SES: 1253 0
UAS: 9323 8524
LOS: 21 0
LOF: 189 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 300566 298
CRC: 28652 0
ES: 7570 4
SES: 2169 0
UAS: 74173 72594
LOS: 151 0
LOF: 444 0
LOM: 1 0
Since Link time = 2 hours 34 min 25 sec
FEC: 414017 858
CRC: 12443 0
ES: 3227 0
SES: 12 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0


[Weaver]

AA clueless detailed CQM graphs. Look how much of the time it has been down. Note the blue spike at around 13:40; I think this is a resynch, and I think it’s due to BT DLM possibly. There was a lot of packet loss at the start of the synched period before this but then things improved a lot. Is it possible that the earlier error rate was high enough to trigger the intervention of BT DLM, forcing a resynch.

[Alex Atkin UK]

I can't find the documents/charts but isn't that pretty much the lowest sync rate ADSL is capable of?  Not really surprising its unstable.

Actually scratch that, I see you were even lower before, I didn't know ADSL could go below around 240kbit.

[Weaver]

I thought 288kbps downstream was the slowest, but as you see on the previous day’s summary then it was 189kbps downstream, and I didn’t know that was possible. It’s been a nuisance having to wait so long with the line being only semi-usable but I was determined to get the best chance of letting an OR engineer see something significant.

[Alex Atkin UK]

Yeah when I saw 288 I was thinking the same thing, though possibly slightly lower but definitely not below 240.

If its the same as VDSL though I remember on Digital Region it was weird as the DSLAM would report a different sync rate to the modem.  I was told its something to do with which value it reports, something about with or without overheads I think.

[Weaver]

An engineer came at about 17:00 today, Thursday, and did some work on a joint at a pole close to the house, the lower pole, right by the road (not the very closest pole to the house). Line cwcc@a.2 is absolutely perfect now. Saga over !! Notes are not back yet, so we’ll hopefully see some answers.

[burakkucat]

An engineer came at about 17:00 today, Thursday, and did some work on a joint at a pole close to the house, the lower pole, right by the road (not the very closest pole to the house).

From the various images I've seen over the years, there are no joints in the cables at the upper (house) pole. It is purely a carrier pole.

At the lower level (road side) pole there are two sets of joints per pair. The first joint (in each pair) is at ground level, where the cable which runs up to the top of the pole is connected to the passing D-side cable. The second joint (in each pair) are gel-crimps, housed in the pole top BT66. The lower level (road side) pole does not have a traditional DP "block and tail".

Line cwcc@a.2 is absolutely perfect now. Saga over !! Notes are not back yet, so we’ll hopefully see some answers.

That's good to know.    (I am assuming that the fault was water ingress.)

[Weaver]

With any luck the notes will come back tomorrow. This could in theory have been fixed a month ago but of course there might have been nothing visible to an engineer back then that could have been located.