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