Print

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

[burakkucat]

I guess that rules out the likelihood of me having my circuit replaced by a contiguous length of 1mm diameter solid silver conductors, twisted pair cable, installed in its own stainless steel butt-welded ducting, 50ft below the ground surface and running in a direct straight line from The Cattery to the cable chamber of EABSE . . .      

[Black Sheep]

It was all do-able, until the point where you mentioned 50ft below ground !! Our ISIS documents state we can only run solid-silver twisted pairs at a depth of 45mtrs !! Damn those regulations !! 

[Mark07]

So since we had the wind / snow the last couple of nights my connection has gone to crap again, asked Plusnet if they can arrange the lift and shift.

I have a feeling the last engineer made no note of him saying about this last time though and it'll be a pain to get them to do it 

Quick stat update - No CRC errors which I was seeing tonnes of last time  could be INP doing it's job 

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 8160 Kbps, Downstream rate = 43296 Kbps
Path: 0, Upstream rate = 8057 Kbps, Downstream rate = 37034 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 6.1
Attn(dB): 0.0 0.0
Pwr(dBm): 12.0 4.5
VDSL2 framing
Path 0
B: 63 238
M: 1 1
T: 64 27
R: 16 16
S: 0.0550 0.9431
L: 11641 2163
D: 587 1
I: 80 255
N: 80 255
Counters
Path 0
OHF: 437855 91200
OHFErr: 0 0
RS: 84067846 628918
RSCorr: 14952 2
RSUnCorr: 0 0

Path 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 82542394 0
Data Cells: 52064 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 0
SES: 0 0
UAS: 20 20
AS: 1161

Path 0
INP: 3.00 0.00
PER: 2.63 12.73
delay: 8.00 0.00
OR: 72.75 20.10

Bitswap: 240 0

Total time = 19 min 42 sec
FEC: 14952 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 20 20
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 4 min 42 sec
FEC: 24745 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 112207 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 20 20
LOS: 0 0
LOF: 0 0
Latest 1 day time = 19 min 42 sec
FEC: 114952 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 20 20
LOS: 0 0
LOF: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 19 min 21 sec
FEC: 114952 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#

[WWWombat]

Something funny with those FEC counts.

In 2 places, it is 114952, but in 2 other places it is 14952. The former is 99 per second (over 1161 seconds), the latter is 12.9 per second.

But FEC is doing the right thing, and correcting them all.

[Mark07]

I didn't even notice that! Any idea why that is, or possibly just a coincidence?

[WWWombat]

A mighty strange coincidence!

I think I've seen times when the first subgroup of stats, the one labelled "Total time = 19 min 42 sec", goes wrong - but IIRC it is the time that goes wrong (the wrong number of days). However, the final subgroup, the one labelled "Since Link time = 19 min 21 sec" is usually trustworthy, as are the other subgroups inbetween.

What do the stats look like now?

[Mark07]

Weird  full current stats below, connection has been fine since the last drop yesterday morning

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 8209 Kbps, Downstream rate = 41076 Kbps
Path: 0, Upstream rate = 8057 Kbps, Downstream rate = 37034 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.0 6.1
Attn(dB): 0.0 0.0
Pwr(dBm): 12.0 4.6
VDSL2 framing
Path 0
B: 63 238
M: 1 1
T: 64 27
R: 16 16
S: 0.0550 0.9431
L: 11641 2163
D: 587 1
I: 80 255
N: 80 255
Counters
Path 0
OHF: 32618577 198824
OHFErr: 70 58
RS: 1967799104 1423188
RSCorr: 181129926 214
RSUnCorr: 2110 0

Path 0
HEC: 517 0
OCD: 0 0
LCD: 0 0
Total Cells: 1854130826 0
Data Cells: 175104080 0
Drop Cells: 0
Bit Errors: 0 0

ES: 23 49
SES: 0 0
UAS: 20 20
AS: 86418

Path 0
INP: 3.00 0.00
PER: 2.63 12.73
delay: 8.00 0.00
OR: 72.75 20.10

Bitswap: 42350 102

Total time = 1 days 39 sec
FEC: 181129926 214
CRC: 70 58
ES: 23 49
SES: 0 0
UAS: 20 20
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 39 sec
FEC: 8800 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 384682 1
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 39 sec
FEC: 8800 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 181121126 214
CRC: 70 58
ES: 23 49
SES: 0 0
UAS: 20 20
LOS: 0 0
LOF: 0 0
Since Link time = 1 days 17 sec
FEC: 181129926 214
CRC: 70 58
ES: 23 49
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
#

[WWWombat]

And that one is perfectly consistent.

The FEC rate is considerably higher now - around 2,000 per second; very close to 10% of all RS blocks need fixing. But the ES count of only 23 over the day shows that the current FEC+Interleaving settings are fixing all those errors.

Ordinarily, the low ES rate would be enough to get DLM to reduce intervention. However, I have seen one other case where the FEC rate was stupidly high, like this, and the ES rate was low (less than 2,800 over 70 days), yet DLM had stayed in place.

It wouldn't surprise me if DLM stayed for you. And it wouldn't surprise me for it to keep FEC+Interleaving even when G.INP becomes available: Retransmission of 10% of all packets isn't likely to be sustainable.

[Mark07]

Yeah I thought that was an insane number, so does this mean there's still an issue somewhere on the line? Wet joint or something maybe?

[WWWombat]

No idea. I can tell you what the digital side is saying, but what that means back in the messy analogue world is harder 

[Mark07]

Thanks for your input, I'll see what PN / OR say 

[Webbs1978]

You're very welcome, bud. 

Apologies for resurrecting an old thread, but I am wondering if a 'lift and shift' as described here can occur from one DSLAM to another? I'm on an ECI cab, with a Huawei cab installed more recently a few yards away. Is it technically possibly to 'lift and shift' a line from the ECI to Huawei?

[j0hn]

Yes.
I've seen it done to a couple different users.
OpenReach will NOT switch cabinet vendors upon request.
The engineer has absolutely no way to request a specific port on a specific cabinet, and they aren't going to try multiple times till you get the cabinet you want.
A lift & shift will only be done if the current port is deemed faulty.

If you want switched from your ECI cabinet to the new Huawei cabinet (I've done exactly this) then you will need to order a 2nd line on the new cab, and then cease the 1st line.

I did it a slightly more complicated way.
It was all documented in this thread

[Webbs1978]

A lift & shift will only be done if the current port is deemed faulty.

This is what occurred to my FTTC line this past week (faulty port). Unfortunately, the engineer did a lift and shift to a port still on the ECI cabinet before then coming to my property to run the usual line tests.