I'm trying hard not to compete with Bald_Eagle_1 for the longest-running VDSL saga, honest.
First the good news.
In case you were still wondering, on Thursday 05/06 at ~05:30, DLM
finally relented after 52days, and set my profile back to 80/20.
=~=~=~=~=~=~=~=~=~=~=~= log 2013.06.05 05:37:10 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 33166 Kbps, Downstream rate = 92028 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate =
79999 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): 0.0 15.2
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 2.3
VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 23 45
R: 0 16
S: 0.0955 0.3782
L: 20107 5373
D: 1 1
I: 240 127
N: 240 254
Path 0
INP: 0.00 0.00
PER: 1.64 4.25
delay: 0.00 0.00
OR: 116.56 60.17
Of course,
on that very day (to be known as day 1) BTOR UG cable teams started working on the same D-side cable from the PCP that supplies my DP and others.
They worked on it for 2 days, tone-tracing pairs, rodding a new cable length and rejointing it. All the while completely oblivious to the concept of always-on DLM-monitored broadband.
Wasn't even my DP!
Fortunately on the second day I was able to power down the modem while they were working in an attempt to avoid the worst impacts. Nevertheless their work resulted in several large transient surges of CRC errors on both days, although the line remained in sync.
On day 3, after they had finished, I was amused to find that DLM regarded their work as serious REIN, imposing an interleaving depth of
1541, and an INP of 3 (8ms delay).
For comparison, the worst interleaving depth ever experienced in many years over the entire 2-3km D- & E-side on ADSL2+ was only 128!
=~=~=~=~=~=~=~=~=~=~=~= log 2013.06.08 11:26:11 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 33974 Kbps, Downstream rate = 92152 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate =
78750 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.3 15.1
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 2.9
VDSL2 framing
Bearer 0
MSGc: 14 26
B: 51 237
M: 1 1
T: 64 45
R: 12 16
S: 0.0210 0.3782
L: 24362 5373
D: 1541 1
I: 64 127
N: 64 254
Bearer 0
INP: 3.00 0.00
INPRein: 0 0
delay: 8 0
PER: 1.34 4.25
OR: 118.95 60.17
It seems only to have replaced modest CRC levels beforehand of say ~<1/sec on fastpath with something like ~7,500 FEC errors a second. All recovered of course, but it does seem like a massive overhead to me.
On a technical note R/N*100 gives the %overhead given over to error-correction, in this case 18.75%.