What A Surprise To Wake Up To!

Hi guys!

Well, here we go! Vectoring has been enabled on my line! I can't believe it! I've noticed that it now takes considerably longer for the CPE to synchronise with the DSLAM, but I don't mind that!

adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8756 Kbps, Downstream rate = 53199 Kbps
Bearer: 0, Upstream rate = 8543 Kbps, Downstream rate = 50526 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Vectoring state: 1
VCE MAC Address: 0:10:fc:20:0:0
Total error samples Ethernet pkts sent: 1791
Total error samples Ethernet pkts discarded: 0
Total error samples statuses sent: 1791
Total error samples statuses discarded: 0

Cheers!

Edited by deleted (Thu 28-Sep-17 10:10:10)

What was your sync prior to Vectoring?

Circa 43 Mb DS, very similar US. Just waiting for the DS SNRM to drop now because it increased to 5 dB after completing those tests earlier in the month. If it drops to 3 dB, then I should be able to get the max DS rate for our package, BT 55/10, which is not bad for a circa 900 m long line!

Edited by deleted (Thu 28-Sep-17 10:09:33)

Anyone else seeing this long synchronisation issue on vectoring?

In reply to a post by WilliamGrimsley:

Anyone else seeing this long synchronisation issue on vectoring?

That is a known downside to vectoring

Any change to the error rates?

In reply to a post by WilliamGrimsley:

very similar US

I think I read that vectoring is only being enabled downstream.

Oh right, how come? No, unfortunately the FEC's continue to rise as normal, so I can't think for the life of me what's causing them. Must be something that affects overhead cables.

Ah, I see.

Edited by deleted (Thu 28-Sep-17 19:46:06)

In reply to a post by WilliamGrimsley:

Oh right, how come?

A little time to syncronise timing with all the other lines, but the majority (I think) comes from having the modem & DSLAM go through additional crosstalk training, where the DSLAM sends a known pilot sequence of symbols, and the modem measures how "far away" from an ideal analogue result each received symbol happens to be.

The modem sends that data back to the DSLAM, which then calculates how those analogue "imperfections" are being caused from each of the other lines. From this, it works out how to negate crosstalk in future.

The part that (I think) makes this process slow is that the DSLAM has to send out that "known pilot sequence of symbols" on both your line and all the other active lines too. Obviously they are in use, so they can only use a small proportion of their symbols.

In reply to a post by WilliamGrimsley:

No, unfortunately the FEC's continue to rise as normal, so I can't think for the life of me what's causing them. Must be something that affects overhead cables.

I guess that, with vectoring turned on, you can now be sure that those FECs aren't being caused by other subscribers. It is come from real external RFI ingress.

Edited by deleted (Thu 28-Sep-17 21:17:20)

That's very interesting, thanks WWWombat! I wonder if Openreach will implement an update which will reduce the time.

Yes, I wonder what's causing it. The only thing I haven't turned off (that could be serving affecting) is our heat pump, because apparently doing that could cause a load of issues. But, I think it's more likely due to the condition of the line (I'd be surprised though as an engineer told me that the line was "perfect" earlier this year, however we have had a lot of wind and rain recently, so the line has been hit by trees and got very damp).

The only other thing I can think of is that the main power line (directly from the local sub station) crosses just above it, so that could be it. The line is overhead so it could also be being affected by the sun. What do you think to that?

Looking at your stats, your line barely gets any DS FEC's, is this because it's underground? I wonder if this issue just affects overhead VDSL lines...

Finally, one other thing I have noticed is that the FEC's don't continually rise, sometimes there can be a few seconds without there being any FEC's, but most of the time there is.

Line stats below:

adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8695 Kbps, Downstream rate = 51012 Kbps
Bearer: 0, Upstream rate = 8482 Kbps, Downstream rate = 50587 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.9 6.2
Attn(dB): 26.7 0.0
Pwr(dBm): 12.1 6.3

VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 227 195
M: 1 1
T: 0 0
R: 10 10
S: 0.1434 0.7328
L: 13282 2249
D: 4 2
I: 238 206
N: 238 206
Q: 4 2
V: 0 0
RxQueue: 120 48
TxQueue: 24 12
G.INP Framing: 18 18
G.INP lookback: 24 12
RRC bits: 24 24
Bearer 1
MSGc: 122 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 8.0000 16.0000
L: 32 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 675218784 132613156
RSCorr: 1683429 54
RSUnCorr: 0 0
Bearer 1
OHF: 1512466 1518564
OHFErr: 0 0
RS: 12099237 6074256
RSCorr: 1714 6
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 42514 27
rtx_c: 42472 27
rtx_uc: 0 0

G.INP Counters
LEFTRS: 0 0
minEFTR: 50592 8479
errFreeBits: 18734047 3133668

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2362767392 0
Data Cells: 133600371 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 0
SES: 0 0
UAS: 120 120
AS: 24298

Bearer 0
INP: 54.00 51.00
INPRein: 1.00 1.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 50697.69 8525.99

Bearer 1
INP: 2.00 4.00
INPRein: 2.00 4.00
delay: 0 0
PER: 16.06 16.06
OR: 63.75 31.87
AgR: 63.75 31.87

Bitswap: 12221/13396 364/374

Total time = 6 hours 46 min 58 sec
FEC: 1683429 54
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 120 120
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Latest 15 minutes time = 1 min 58 sec
FEC: 1142 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 14122 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 6 hours 46 min 58 sec
FEC: 1683429 54
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 120 120
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 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
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 6 hours 44 min 57 sec
FEC: 1683429 54
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0

Edited by deleted (Thu 28-Sep-17 23:11:39)

A selling point of G.fast is faster sync times compared to a figure of two minutes on Vectored VDSL2

DLM has just decreased the DS SNRM to 4 dB by initiating a resync, here are the line stats after a power down and up of the CPE:

adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8688 Kbps, Downstream rate = 54534 Kbps
Bearer: 0, Upstream rate = 8688 Kbps, Downstream rate = 52190 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.7 6.3
Attn(dB): 26.6 0.0
Pwr(dBm): 12.1 6.2

VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 227 227
M: 1 1
T: 0 0
R: 10 10
S: 0.1389 0.8347
L: 13703 2281
D: 4 4
I: 238 238
N: 238 238
Q: 4 4
V: 0 0
RxQueue: 125 15
TxQueue: 25 5
G.INP Framing: 18 18
G.INP lookback: 25 5
RRC bits: 24 24
Bearer 1
MSGc: 122 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 8.0000 16.0000
L: 32 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 1405112 235253
RSCorr: 446 0
RSUnCorr: 0 0
Bearer 1
OHF: 3112 3068
OHFErr: 0 0
RS: 24404 12273
RSCorr: 0 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 107 0
rtx_c: 110 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 0 0
minEFTR: 52157 8691
errFreeBits: 39787 6336

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 5016645 0
Data Cells: 3817 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 0
SES: 0 0
UAS: 115 115
AS: 50

Bearer 0
INP: 55.00 46.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 52304.65 8706.62

Bearer 1
INP: 2.00 4.00
INPRein: 2.00 4.00
delay: 0 0
PER: 16.06 16.06
OR: 63.75 31.87
AgR: 63.75 31.87

Bitswap: 14/14 1/1

Total time = 2 min 45 sec
FEC: 446 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 115 115
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Latest 15 minutes time = 2 min 45 sec
FEC: 446 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 115 115
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 2 min 45 sec
FEC: 446 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 115 115
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 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
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 49 sec
FEC: 446 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0

Edited by deleted (Fri 29-Sep-17 10:30:16)

In reply to a post by MrSaffron:

A selling point of G.fast is faster sync times compared to a figure of two minutes on Vectored VDSL2

how faster sync times?

5 secs, 30 secs or 1 min?

Was just a few seconds, but that was in the labs, rather than a live customer with full production kit.

In reply to a post by WilliamGrimsley:

I wonder if Openreach will implement an update which will reduce the time.

Nope. The time is nothing to do with Openreach, and everything to do with the ITU standard.

In reply to a post by WilliamGrimsley:

What do you think to that?

Didn't I comment to your last thread in the other forum on here?

There's no data available on MDWS to look at FECs, but I recall that the pattern of FECs across each day made it unlikely to be individual pieces of equipment, or mains wiring.

Other than that, I don't have a scooby.

In reply to a post by WilliamGrimsley:

Looking at your stats, your line barely gets any DS FEC's, is this because it's underground? I wonder if this issue just affects overhead VDSL lines...

Mine is short. Half underground, then along someone's fence (!), then once it reaches the DP on a wall, the drop wire runs for maybe 40m above ground.

Hmm, my line must be getting slowly shredded by the trees then! No surprise there! That's comforting to know, the last thing I want is a device impacting our connection.

That's some interesting cable routing.

Ah, well I may as well just leave everything as it is and only become concerned when CRC's start accumulating. LOL.

I wouldn't worry about FEC's, I used to millions a minute on our works line and it didn't affect our service. Sometimes they'd just start then months later almost disappear again. Haven't seen them like that for a long time now though. Our lines underground, but on an industrial estate.

Hmm, interesting. Is that on INP + Interleaving or G.INP + Interleaving?

ECI cabinet interleaved, you don't get many if any FEC errors on fast path IIRC.

Ah, yeah that's quite normal. But, on G.INP it's not.

WOW! I didn't expect my line's DS rate to be able to connect at the max for my package: BT 55/10!

adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7293 Kbps, Downstream rate = 57676 Kbps
Bearer: 0, Upstream rate = 7940 Kbps, Downstream rate = 54997 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 4.3 6.3
Attn(dB): 26.5 0.0
Pwr(dBm): 11.9 6.1

VDSL2 framing
Bearer 0
MSGc: -6 26
B: 227 239
M: 1 1
T: 0 42
R: 10 0
S: 0.1319 0.9605
L: 14440 1999
D: 4 1
I: 238 120
N: 238 240
Q: 4 0
V: 0 0
RxQueue: 130 0
TxQueue: 26 0
G.INP Framing: 18 0
G.INP lookback: 26 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

Counters
Bearer 0
OHF: 0 21128
OHFErr: 0 0
RS: 6436456 887015
RSCorr: 41471 0
RSUnCorr: 0 0
Bearer 1
OHF: 13322 0
OHFErr: 0 0
RS: 106085 0
RSCorr: 14 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 699 0
rtx_c: 699 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 0 0
minEFTR: 54960 0
errFreeBits: 179407 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 22623493 0
Data Cells: 1793806 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 0
SES: 0 0
UAS: 117 117
AS: 214

Bearer 0
INP: 54.00 0.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 10.12
OR: 0.01 25.28
AgR: 55117.80 7964.88

Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01

Bitswap: 77/94 1/1

Total time = 5 min 31 sec
FEC: 41471 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 117 117
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Latest 15 minutes time = 5 min 31 sec
FEC: 41471 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 117 117
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Previous 15 minutes time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
FailedRetr: N/A
FailedFastRetr: N/A
Latest 1 day time = 5 min 31 sec
FEC: 41471 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 117 117
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 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
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
Since Link time = 3 min 33 sec
FEC: 41471 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
FailedRetr: 0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0

William do you know if you in a BDUK area?

Hi Chrys!

Nice to hear from you! I hope you're well!

Yes, I'm connected to a BDUK cabinet, Cabinet 1, which is connected to the Colaton Raleigh exchange. The cabinet has a lot of long lines connected to it, so it would make sense for it to have vectoring enabled.

Edited by deleted (Wed 04-Oct-17 09:41:52)

Sync speed isn't everything.

Looks like you're on high retransmission which means your IP Profile will be 91% of your sync speed

Yes, I'm fully aware... Knowing that my line experiences DS SNRM swings and dips, then if it wasn't on high retransmission, there would be a lot more errors! So, I'm actually glad that it is!

Edited by deleted (Wed 04-Oct-17 10:02:46)