Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: hushcoden on February 05, 2018, 01:49:45 PM
-
Those are the current stats of my line and I'd like to understand whether or not I should be concerned about the high value of FECs
xdslctl info --webstats
====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 10 days: 4 hours: 39 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 10.146 Mbps 40.072 Mbps
Actual Net Data Rate: 9.995 Mbps 39.994 Mbps
Trellis Coding: ON ON
SNR Margin: 16.1 dB 16.8 dB
Actual Delay: 0 ms 8 ms
Transmit Power: 1.2 dBm 1.2 dBm
Receive Power: -6.6 dBm 0.5 dBm
Actual INP: 0.0 symbols 3.0 symbols
Total Attenuation: 0.0 dB 14.9 dB
Attainable Net Data Rate: 22.889 Mbps 87.928 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.3 19.3 23.9 N/A N/A 9.9 20.0 33.4
Signal Attenuation(dB): 0.2 19.3 23.8 N/A N/A 10.1 19.9 33.4
SNR Margin(dB): 13.7 0.0 16.2 N/A N/A 16.8 16.8 16.8
TX Power(dBm): -6.5 -128.0 0.3 N/A N/A 9.3 7.2 7.5
====================================================================================
VDSL Counters
Downstream Upstream
Since Link time = 39 min 3 sec
FEC: 3557727 20
CRC: 511 2
ES: 256 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 4 min 27 sec
FEC: 1411 0
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: 5460 0
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 = 15 hours 49 min 27 sec
FEC: 296110 0
CRC: 33 0
ES: 13 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 339859 6
CRC: 73 0
ES: 34 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Total time = 1 days 15 hours 49 min 27 sec
FEC: 3557727 20
CRC: 511 2
ES: 4499 3
SES: 18 0
UAS: 70 60
LOS: 1 0
LOF: 7 0
LOM: 0 0
====================================================================================
-
It's the errored seconds and severely errored seconds count that you need to worry about, as that is what triggers DLM to intervene.
In your case it already has done so, as you have interleaving on your downstream.
-
Those are the current stats of my line and I'd like to understand whether or not I should be concerned about the high value of FECs
xdslctl info --webstats
====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 10 days: 4 hours: 39 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 10.146 Mbps 40.072 Mbps
Actual Net Data Rate: 9.995 Mbps 39.994 Mbps
Trellis Coding: ON ON
SNR Margin: 16.1 dB 16.8 dB
Actual Delay: 0 ms 8 ms
Transmit Power: 1.2 dBm 1.2 dBm
Receive Power: -6.6 dBm 0.5 dBm
Actual INP: 0.0 symbols 3.0 symbols
Total Attenuation: 0.0 dB 14.9 dB
Attainable Net Data Rate: 22.889 Mbps 87.928 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.3 19.3 23.9 N/A N/A 9.9 20.0 33.4
Signal Attenuation(dB): 0.2 19.3 23.8 N/A N/A 10.1 19.9 33.4
SNR Margin(dB): 13.7 0.0 16.2 N/A N/A 16.8 16.8 16.8
TX Power(dBm): -6.5 -128.0 0.3 N/A N/A 9.3 7.2 7.5
====================================================================================
VDSL Counters
Downstream Upstream
Since Link time = 39 min 3 sec
FEC: 3557727 20
CRC: 511 2
ES: 256 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 4 min 27 sec
FEC: 1411 0
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: 5460 0
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 = 15 hours 49 min 27 sec
FEC: 296110 0
CRC: 33 0
ES: 13 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 339859 6
CRC: 73 0
ES: 34 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Total time = 1 days 15 hours 49 min 27 sec
FEC: 3557727 20
CRC: 511 2
ES: 4499 3
SES: 18 0
UAS: 70 60
LOS: 1 0
LOF: 7 0
LOM: 0 0
====================================================================================
No. I get between 5000 - 50000 FEC per minute. It's absolutely nothing to worry about.
FEC's are errors that didn't happen.
-
jaydub, j0hn, many thanks !
I believe the interleave info comes from the "Actual Delay", correct? So, under Downstream is not 0 so it is interleaved... Never mind, let's hope the connection will keep stable :baby:
Also, would it make any sense to try a different modem (mine is a VMG1312-B10A) i.e. Draytek 2760 (which if I am not mistaken it's not BCM but Lantiq) to see if it would produce less errors ?
-
The important figures are INP and delay.
You have INP = 3 which is low interleaving.
You have an 8ms delay (8ms increase in ping for example).
The interleaving number is pretty irrelevant, and changes with sync level.
-
Is there a way to bring down the actual delay from 8ms to 0ms as well as INP ?
-
Usually capping the sync and significantly reducing errors will shake interleaving. You need to cap the line low enough to get ES numbers down to single figures per 24 hour.
Can you post xdslctl info --stats so I can see the recent line stats. Then I could recommend a cap that would shake interleaving.
From the stats you posted previously the line looked quite noisy and might not be able to hold fastpath.
-
I would do my best to understand what is a FEC it's a Forward error correction is, here is a cut and paste.
Definition - What does Forward Error Correction (FEC) mean?
Forward error correction (FEC) is a digital signal processing technique used to enhance data reliability. It does this by introducing redundant data, called error correcting code, prior to data transmission or storage. FEC provides the receiver with the ability to correct errors without a reverse channel to request the retransmission of data.
The first FEC code, called a Hamming code, was introduced in the early 1950s. It is a method adopted to obtain error control in data transmission where the transmitter sends redundant data. Only a portion of the data without apparent errors is recognized by the receiver. This allows broadcasting data to be sent to multiple destinations from a single source.
Forward error coding is also known as channel coding.
Techopedia explains Forward Error Correction (FEC)
FEC adds redundancy to transmitted information using a predetermined algorithm. The redundant bits are complex functions of the original information bits. Bits are sent multiple times, because an error may appear in any of the samples transmitted. FEC codes generally detect the last set of bits to determine the decoding of a small handful of bits.
With FAC, each character is sent two or three times, and the receiver checks instances of each character. It is accepted only if conformity occurs in both instances. If conformity is satisfied for an instance, the character conforming to the protocol is accepted. If no characters conform to the protocol, the character is rejected and an underscore or blank is displayed in its place.
FEC codes are capable of generating bit error rate signals, which are used as feedback to fine-tune the analog receiving electronics. The maximum number of missing bits that can be corrected is determined by the FEC code design. Two important categories of FEC codes are convolutional codes and block codes. The block codes work on fixed-size packets of bits where the partial code blocks are decoded in polynomial time to the block length. A widely used block code is Reed-Solomon coding. Convolutional codes deal with streams of arbitrary length and are decoded using a Viterbi algorithm. An important feature of convolutional code is that any bit encoding is influenced by the preceding bits.
-
Those are the latest stats:
====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 44 days: 7 hours: 16 minutes
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 10.146 Mbps 40.072 Mbps
Actual Net Data Rate: 9.995 Mbps 39.994 Mbps
Trellis Coding: ON ON
SNR Margin: 15.9 dB 14.6 dB
Actual Delay: 0 ms 8 ms
Transmit Power: 1.2 dBm 1.2 dBm
Receive Power: -6.6 dBm 0.5 dBm
Actual INP: 0.0 symbols 3.0 symbols
Total Attenuation: 0.0 dB 14.9 dB
Attainable Net Data Rate: 22.625 Mbps 78.092 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.3 19.3 23.9 N/A N/A 9.9 20.0 33.4
Signal Attenuation(dB): 0.2 19.3 23.8 N/A N/A 10.1 19.9 33.4
SNR Margin(dB): 13.8 0.0 16.0 N/A N/A 14.6 14.5 14.5
TX Power(dBm): -6.5 -128.0 0.3 N/A N/A 9.3 7.2 7.5
====================================================================================
VDSL Counters
Downstream Upstream
Since Link time = 16 min 11 sec
FEC: 13724185 156
CRC: 1775 13
ES: 884 13
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 36 sec
FEC: 8931 0
CRC: 3 0
ES: 1 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: 1052 0
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 = 18 hours 26 min 36 sec
FEC: 248372 6
CRC: 19 1
ES: 7 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 257067 5
CRC: 5 1
ES: 3 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Total time = 1 days 18 hours 26 min 36 sec
FEC: 13724185 156
CRC: 1775 13
ES: 5127 14
SES: 18 0
UAS: 70 60
LOS: 1 0
LOF: 7 0
LOM: 0 0
====================================================================================
-
xdslctl info --stats would have given me the additional line parameters, but I can still see the errors from that. I don't like the 884 ES in 16 mins since link time.
Considering your line is already capped at 40Mb (it's capable of nearly 80Mb) it may well revert right back to interleaving, but this cap should remove it.
xdslctl configure --maxDataRate 30000 10000 100000
It will cap the line at 30Mb down and should reduce the ES/FEC enough to revert to fastpath.
It should take 2-8 days depending on previous DLM interventions on your line.
-
I don't like the 884 ES in 16 mins since link time.
Assuming it's a Zyxel (sorry I haven't read the entire thread), mine does the same on the web GUI stats output. I imagine it's a bug. Note that his link time claims to be 'Link Uptime: 44 days: 7 hours: 16 minutes' above all the usual error counters, while 'Since Link time = 16 min 11 sec' is only partly correct (missing the hours and days). However his 'total time' at the bottom is only claiming to be more than a day, so I don't know what is necessarily true from that output. The web GUI stats output is not as reliable as the telnet stats output.
-
Oh sorry I ran the command with --webstats...
This is the command with the option --stats:
> xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22660 Kbps, Downstream rate = 77933 Kbps
Bearer: 0, Upstream rate = 9995 Kbps, Downstream rate = 39994 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): 14.5 15.9
Attn(dB): 14.9 0.0
Pwr(dBm): 1.2 1.2
VDSL2 framing
Bearer 0
MSGc: 18 219
B: 31 235
M: 1 1
T: 64 7
R: 10 16
S: 0.0255 0.7508
L: 13200 2717
D: 1283 1
I: 42 255
N: 42 255
Counters
Bearer 0
OHF: 1564245243 1081372
OHFErr: 1792 13
RS: 3669564313 937110
RSCorr: 13807236 156
RSUnCorr: 6787 0
Bearer 0
HEC: 982 0
OCD: 0 0
LCD: 0 0
Total Cells: 3079202053 0
Data Cells: 1649028873 0
Drop Cells: 0
Bit Errors: 0 0
ES: 5136 14
SES: 18 0
UAS: 70 60
AS: 3837992
Bearer 0
INP: 3.50 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 2.45 11.87
OR: 78.26 151.62
AgR: 40072.04 10146.45
Bitswap: 291472/292352 4/4
Total time = 47 days 21 hours 16 min 56 sec
FEC: 13807236 156
CRC: 1792 13
ES: 5136 14
SES: 18 0
UAS: 70 60
LOS: 1 0
LOF: 7 0
LOM: 0 0
Latest 15 minutes time = 1 min 56 sec
FEC: 181 0
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: 3325 0
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 = 21 hours 16 min 56 sec
FEC: 331423 6
CRC: 36 1
ES: 16 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 257067 5
CRC: 5 1
ES: 3 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 44 days 10 hours 6 min 31 sec
FEC: 13807236 156
CRC: 1792 13
ES: 893 13
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
And yes I have a Zyxel VMG1312-B10A
-
xdslctl info --stats would have given me the additional line parameters, but I can still see the errors from that. I don't like the 884 ES in 16 mins since link time.
Considering your line is already capped at 40Mb (it's capable of nearly 80Mb) it may well revert right back to interleaving, but this cap should remove it.
xdslctl configure --maxDataRate 30000 10000 100000
It will cap the line at 30Mb down and should reduce the ES/FEC enough to revert to fastpath.
It should take 2-8 days depending on previous DLM interventions on your line.
And to remove this cap I just reboot the rooter ?
The router is in bridge mode, does it make any difference?
-
And to remove this cap I just reboot the rooter ?
The router is in bridge mode, does it make any difference?
Yes, rebooting clears the cap.
No, bridge mode is irrelevant here.
-
Eventually I decided to give it a try, fingers crossed...
Those are the stats after the cap:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 21905 Kbps, Downstream rate = 89797 Kbps
Bearer: 0, Upstream rate = 9995 Kbps, Downstream rate = 29993 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): 20.6 15.8
Attn(dB): 14.9 0.0
Pwr(dBm): 1.7 1.7
VDSL2 framing
Bearer 0
MSGc: 24 219
B: 31 235
M: 1 1
T: 64 7
R: 10 16
S: 0.0339 0.7508
L: 9904 2717
D: 961 1
I: 42 255
N: 42 255
Counters
Bearer 0
OHF: 504953 139682
OHFErr: 0 0
RS: 193785879 208346
RSCorr: 2357 0
RSUnCorr: 0 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 95226526 0
Data Cells: 5256332 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1 0
SES: 0 0
UAS: 69 69
AS: 1652
Bearer 0
INP: 3.50 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 3.26 11.87
OR: 73.40 151.62
AgR: 30066.17 10146.45
Bitswap: 39/39 0/0
Total time = 1 hours 13 min 27 sec
FEC: 20360 0
CRC: 4 0
ES: 1 0
SES: 0 0
UAS: 69 69
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 13 min 27 sec
FEC: 35 0
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: 2339 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 39 39
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 1 hours 13 min 27 sec
FEC: 20360 0
CRC: 4 0
ES: 1 0
SES: 0 0
UAS: 69 69
LOS: 0 0
LOF: 0 0
LOM: 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
LOM: 0 0
Since Link time = 27 min 31 sec
FEC: 2357 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
Does anyone know if limiting sync speed is safe?
The DLM or whatever doesn't start thinking that is the max speed of the line and start using it for diagnosing line problems or for setting the hand back thresholds?
Lowering your hand back thresholds would not be the best thing to do?
I have always been reluctant to apply a cap due to these concerns?
Thanks
-
I think there's a risk it might apply banding itself if it sees the sync rate/SNR margin wildly fluctuate/change, which is probably why my first line is currently banded (for some reason it got re-synced much lower after the engineer did the second line at the cabinet, FTTC, and it has a much higher attainable rate).
-
@hushcoden - have you actually rebooted as it doesn't appear to have cleared your cap. You're still stuck on a DS sync of 30k.
:no:
-
Does anyone know if limiting sync speed is safe?
The DLM or whatever doesn't start thinking that is the max speed of the line and start using it for diagnosing line problems or for setting the hand back thresholds?
Lowering your hand back thresholds would not be the best thing to do?
I have always been reluctant to apply a cap due to these concerns?
Thanks
I can say that I honestly don't know, but I would also be rather concerned for the reasons you highlighted. As the DLM is always collecting stats, there is no reason to why it would not adjust estimates and handback in relation to the line's performance. But that's, to some degree, an assumption as I have no solid proof though it is plausible considering estimates do change based on conditions.
Perhaps someone here has read some BT documentation, but maybe they can't disclose the inner workings. :-\
-
@hushcoden - have you actually rebooted as it doesn't appear to have cleared your cap. You're still stuck on a DS sync of 30k.
:no:
Well, my line is 40/10 and now with cap is 30/10, correct?
Anyway, I will keep this cap for 48 hours and then I will reboot the ZyXEL and this should remove the cap...
-
Ah, I misunderstood - you have just applied the cap (I was thinking you were trying to release it :-[).
Here's hoping it works.
:)
-
So I've rebooted the rooter after 72 hours and it seems this made the trick :graduate:
xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 22531 Kbps, Downstream rate = 81398 Kbps
Bearer: 0, Upstream rate = 9995 Kbps, Downstream rate = 39970 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): 17.5 16.0
Attn(dB): 15.0 0.0
Pwr(dBm): 1.6 1.6
VDSL2 framing
Bearer 0
MSGc: 19 219
B: 239 235
M: 1 1
T: 64 7
R: 0 16
S: 0.1911 0.7508
L: 10048 2717
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 1801732 467794
OHFErr: 150 0
RS: 0 3695479
RSCorr: 0 0
RSUnCorr: 0 0
Bearer 0
HEC: 329 0
OCD: 0 0
LCD: 0 0
Total Cells: 425069939 0
Data Cells: 32990935 0
Drop Cells: 0
Bit Errors: 0 0
ES: 87 0
SES: 0 0
UAS: 30 30
AS: 5532
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 3.06 11.87
OR: 65.16 151.62
AgR: 40035.61 10146.45
Bitswap: 243/243 0/0
Total time = 1 hours 32 min 42 sec
FEC: 0 0
CRC: 150 0
ES: 87 0
SES: 0 0
UAS: 30 30
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 2 min 42 sec
FEC: 0 0
CRC: 19 0
ES: 8 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: 0 0
CRC: 67 0
ES: 28 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 1 hours 32 min 42 sec
FEC: 0 0
CRC: 150 0
ES: 87 0
SES: 0 0
UAS: 30 30
LOS: 0 0
LOF: 0 0
LOM: 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
LOM: 0 0
Since Link time = 1 hours 32 min 11 sec
FEC: 0 0
CRC: 150 0
ES: 87 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
-
So unlucky... it seems my line doesn't like a delay=0 and INP=0, so after 5 days I am back to square one
> xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22327 Kbps, Downstream rate = 88961 Kbps
Bearer: 0, Upstream rate = 9995 Kbps, Downstream rate = 39994 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): 16.5 15.9
Attn(dB): 15.0 0.0
Pwr(dBm): 1.7 1.6
VDSL2 framing
Bearer 0
MSGc: 18 219
B: 31 235
M: 1 1
T: 64 7
R: 10 16
S: 0.0255 0.7508
L: 13200 2717
D: 1283 1
I: 42 255
N: 42 255
Counters
Bearer 0
OHF: 48701237 173611
OHFErr: 27 0
RS: 1521251008 885830
RSCorr: 320256 0
RSUnCorr: 234 0
Bearer 0
HEC: 41 0
OCD: 0 0
LCD: 0 0
Total Cells: 598865071 0
Data Cells: 109209334 0
Drop Cells: 0
Bit Errors: 0 0
ES: 3577 0
SES: 36 0
UAS: 70 60
AS: 119494
Bearer 0
INP: 3.50 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 2.45 11.87
OR: 78.26 151.62
AgR: 40072.04 10146.45
Bitswap: 4511/4513 0/0
Total time = 5 days 42 min 55 sec
FEC: 320256 0
CRC: 27 0
ES: 3577 0
SES: 36 0
UAS: 70 60
LOS: 1 0
LOF: 7 0
LOM: 0 0
Latest 15 minutes time = 12 min 55 sec
FEC: 3911 0
CRC: 2 0
ES: 1 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: 3695 0
CRC: 3 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 42 min 55 sec
FEC: 16940 0
CRC: 5 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 215707 0
CRC: 18 0
ES: 9 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 9 hours 11 min 33 sec
FEC: 320256 0
CRC: 27 0
ES: 12 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0Never mind, that's probably also due to the fact I am connected to the 'best in class' ECI cab :crazy:
-
Have you tried a different modem, maybe even a Lantiq one?
-
I'd definitely try another modem with a Lantiq/Infineon chipset. In my experience they work better in terms of error rates and tend to give the best latency too (up to a few milliseconds less than Broadcom on ECI DSLAM's) albeit at a cost of a slight reduction in attainable downstream sync rate.
-
Right then, will try to find a second hand Vigor 130...
And one question: from the stats I see my line is Annex B, so does it mean I should flash the Vigor 130 with the Annex B firmware rather than with the Annex A one ?
-
Probably not, because that Draytek firmware is probably referring to the ADSL Annex.
ADSL Annex A is ADSL over POTS - what we use in the UK
ADSL Annex B is ADSL over ISDN
VDSL2 Annex A is bandplans for North America
VDSL2 Annex B is bandplans for Europe
-
Thanks ejs, I will double-check but I remember I have seen stats of some member of the forum (UK based) where their line was VDSL2 Annex A :-\
-
Unfortunately some devices can be rather ambiguous as to which annex they are referring to.
-
Thanks ejs, I will double-check but I remember I have seen stats of some member of the forum (UK based) where their line was VDSL2 Annex A :-\
We most definitely use VDSL2 Annex B Profile 17a in the UK.
A number of devices incorrectly report Annex A.
-
I'd definitely try another modem with a Lantiq/Infineon chipset. In my experience they work better in terms of error rates and tend to give the best latency too (up to a few milliseconds less than Broadcom on ECI DSLAM's) albeit at a cost of a slight reduction in attainable downstream sync rate.
I guess it must be line specific...but in my experience it's the exact opposite. I'm on an ECI cabinet, normally using a Broadcom based modem. Due to a noise burst over the w/e I'm on high interleaving, banded at 15Mb. As a test, I just switched back to my Lantiq-based HH5a and got a DS sync of 10706 @ 6.1 db - ping to bbc.news.co.uk was 50ms. Immediately put a VMG8924-B10A back on the line and got a DS sync of 14563 @ 6.3db - ping to bbc.news.co.uk was 30ms... (Normally I'd hit the banding of 15000 but at this time of night the SNRM is very low so sometimes it syncs just under). I've previously tried a Draytek 2760 and got a similarly poor DS sync, although I didn't try a ping as I just wanted to put it back in its box and return it to sender!
-
Every line is different but with my ECI cab line I swear by my VMG8324 B10A - *not* the D version.
-
I guess it must be line specific...but in my experience it's the exact opposite. I'm on an ECI cabinet, normally using a Broadcom based modem. Due to a noise burst over the w/e I'm on high interleaving, banded at 15Mb. As a test, I just switched back to my Lantiq-based HH5a and got a DS sync of 10706 @ 6.1 db - ping to bbc.news.co.uk was 50ms. Immediately put a VMG8924-B10A back on the line and got a DS sync of 14563 @ 6.3db - ping to bbc.news.co.uk was 30ms... (Normally I'd hit the banding of 15000 but at this time of night the SNRM is very low so sometimes it syncs just under). I've previously tried a Draytek 2760 and got a similarly poor DS sync, although I didn't try a ping as I just wanted to put it back in its box and return it to sender!
Probably line specific, though I can't comment as to the performance of the HH5a. I don't trust ISP supplied and branded equipment :P. Lantiq/Infineon chipsets tend to sync slightly lower on fastpath, possibly on traditional interleaving too. For fastpath it's due to the fact they apply an 'R' (reed solomon coding) of 16, a light form of error correction. The Broadcom chipset doesn't seem to do this on fastpath (R: 0).