Kitz Forum
Broadband Related => Broadband Technology => Topic started by: Weaver on October 06, 2016, 04:04:21 PM
-
When modems report "HEC errors" I wonder if they are counting (i) detected errors, or (ii) number of cells with at least one detected error, or (iii) uncorrectable errors? If it's not the latter then you don't have to really worry, it's just potential trouble ahead. It would be interesting to know what the three individual counts are.
-
One other thing: For some reason, I'm not seeing downstream HEC counts any more, AA just report "N/A". This started when I went 21CN. Don't suppose there is any chance I'm using PTM instead of ATM now I'm on ADSL2 ? Can't remember what we said about the availability of PTM when we were discussing it earlier.
Does anyone else who is on ADSL2/2+ see no reporting of HEC errors? Or any indication they might be using PTM?
-
I remember now, ejs thought no-one actually uses PTM in G.992.3 (ADSL2) -
http://forum.kitz.co.uk/index.php/topic,18489.msg333398.html#msg333398
-
As you will recall, my service is configured as G.992.5 from the TalkTalk (exchange based) MSAN and due to the length of the line (& thus the circuit's attenuation) I have configured my modem/router (a ZyXEL VMG1312-B10D) to G.992.3 mode.
(Observation: I note that the modem/router will allow me to configure the usage of either ATM or PTM for G.992.{1|3|5} mode. Whether I would be able to establish a viable link, I do not know . . . for I have not tried it.)
Here follows the output of the "xdslctl info", the "xdslctl info --state", the "xdslctl info --show" and the "xdslctl info --stats" command lines --
ZyXEL login: admin
Password:
BusyBox v1.20.1 (2016-06-06 11:34:28 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
$ xdslctl info
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 1028 Kbps, Downstream rate = 5732 Kbps
Bearer: 0, Upstream rate = 1011 Kbps, Downstream rate = 5448 Kbps
$ xdslctl info --state
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 1020 Kbps, Downstream rate = 5772 Kbps
Bearer: 0, Upstream rate = 1011 Kbps, Downstream rate = 5448 Kbps
$ xdslctl info --show
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 1032 Kbps, Downstream rate = 5776 Kbps
Bearer: 0, Upstream rate = 1011 Kbps, Downstream rate = 5448 Kbps
Link Power State: L0
Mode: ADSL2 Annex A
TPS-TC: ATM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.2 6.1
Attn(dB): 46.0 28.9
Pwr(dBm): 0.0 12.8
ADSL2 framing
Bearer 0
MSGc: 61 10
B: 165 46
M: 1 4
T: 1 3
R: 6 4
S: 0.9690 5.9077
L: 1420 260
D: 64 4
Counters
Bearer 0
SF: 856235 784262
SFErr: 353 28
RS: 57367668 819831
RSCorr: 31583 58
RSUnCorr: 6215 0
Bearer 0
HEC: 3091 18
OCD: 0 0
LCD: 0 0
Total Cells: 178597862 33037026
Data Cells: 4058805 381229
Drop Cells: 0
Bit Errors: 338322 2823
ES: 140 21
SES: 0 0
UAS: 51 51
AS: 13896
Bearer 0
INP: 1.00 0.00
INPRein: 0.00 0.00
delay: 16 6
PER: 16.23 17.72
OR: 33.02 7.22
AgR: 5460.53 1014.37
Bitswap: 184/184 16/16
$ xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 8000
Last initialization procedure status: 0
Max: Upstream rate = 1032 Kbps, Downstream rate = 5772 Kbps
Bearer: 0, Upstream rate = 1011 Kbps, Downstream rate = 5448 Kbps
Link Power State: L0
Mode: ADSL2 Annex A
TPS-TC: ATM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 6.1
Attn(dB): 46.0 28.9
Pwr(dBm): 0.0 12.8
ADSL2 framing
Bearer 0
MSGc: 61 10
B: 165 46
M: 1 4
T: 1 3
R: 6 4
S: 0.9690 5.9077
L: 1420 260
D: 64 4
Counters
Bearer 0
SF: 856977 784941
SFErr: 353 28
RS: 57417352 827980
RSCorr: 31583 58
RSUnCorr: 6215 0
Bearer 0
HEC: 3091 18
OCD: 0 0
LCD: 0 0
Total Cells: 178752538 33065688
Data Cells: 4058808 381235
Drop Cells: 0
Bit Errors: 338322 2823
ES: 140 21
SES: 0 0
UAS: 51 51
AS: 13907
Bearer 0
INP: 1.00 0.00
INPRein: 0.00 0.00
delay: 16 6
PER: 16.23 17.72
OR: 33.02 7.22
AgR: 5460.53 1014.37
Bitswap: 184/184 16/16
Total time = 3 hours 52 min 42 sec
FEC: 31583 58
CRC: 353 28
ES: 140 21
SES: 0 0
UAS: 51 51
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Latest 15 minutes time = 7 min 42 sec
FEC: 241 0
CRC: 2 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 233 0
CRC: 2 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
Latest 1 day time = 3 hours 52 min 42 sec
FEC: 31583 58
CRC: 353 28
ES: 140 21
SES: 0 0
UAS: 51 51
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 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
Since Link time = 3 hours 51 min 51 sec
FEC: 31583 58
CRC: 353 28
ES: 140 21
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
$
Note that HECs are reported by the "--show" and "--stats" variants of the "xdslctl info" command line.
-
Extremely useful, many thanks. These figures have typically (and understandably) terse labels. I wonder if anything can be deduced from their values as to what their precise meaning is. I noticed that RS-related event counters are broken down in more helpful detail.
The PTM experiment would be very interesting.
-
I think HEC errors should be reporting the number of cells with one or more errors, I'm not sure if it can detect the exact number of bit errors in the cell header. All HEC errors are uncorrected. ATM HEC in general is able to correct single bit errors in the cell header, but the error correction is not used on DSL - refer to G.992.3 K.2.8.5.
-
These figures have typically (and understandably) terse labels. I wonder if anything can be deduced from their values as to what their precise meaning is.
I am aware of a page (http://www.kitz.co.uk/adsl/linestats_errors.htm) on a useful website (http://www.kitz.co.uk/) which explains a number of those terse labels. ;)
The PTM experiment would be very interesting.
I shall make a note to remind myself to perform the experiment.
-
@ejs thanks for pointing that out. I wonder why the authors chose to ban HEC error correction.
-
The experiment, attempting to use PTM on a G.992.3 configured circuit, was performed. It was totally unsuccessful. :(
No matter how I manipulated the configuration, a working connection was impossible to attain. :no:
By the time I had finished the experiment, I had to resort to loading the saved configuration file to regain Internet access. ::)
-
It seems like a real missed opportunity. I wonder how many modems offer PTM as an option?
-
A little thought keeps niggling. :-\ So much so, I have decided to try the experiment again at a later date when more time is available.
-
Many thanks for that, it's good to know.
I realise now that this is perhaps only relevant in the case of TT DSLAMs, as presumably you are on TT LLU? (I'm assuming, don't know why, that TT is LLU-only? Is that the case?)
I wonder if any kitizens could test on ADSLx using a BT DSLAM?
-
Just seen this. It definitely wouldn't work with BTw 20CN as they run an ATM backhaul.
Different framing methods and circuit paths.
ATM uses VCs and VPs, your connection is set up to run over a specific Virtual Path through ATM switches.
PTM uses HDLC and VLANs. ATM needs AAL5.
Put it into PTM mode and your traffic will go nowhere.
Square peg into round hole springs to mind.
-
Kitz, I'm aware this is true for 20CN. I'm 21CN ADSL2. And Burakkucat is * ADSL2. Is that true for him too, that ATM extends beyond the DSLAM ?
(The experiment is not open to G.992.1 users.)
-
Without going into networking and protocol depth and the OSI model, ADSL2+ has a layer 2 switch 'behind' the MSAN.
ATM is used on the link between modem and MSAN.
AAL5 is what does all the converting between Ethernet and ATM.. and then back again before it can go on to the 21CN backhaul.
Presumably TT uses an ethernet backhaul.
Theres a reason why ATM was invented and it has its advantages for ADSL.
-
Yes, my TalkTalk circuit is MPF (using the Openreach terminology) i.e. LLU (using Ofcom terminology). The TalkTalk MSAN will accept my CPE connecting in any one of G.992.1, G.992.3 and G.992.5 modes. G.992.5 is pointless due to the line length involved. Hence G.992.3 is my preferred mode.
The little niggle is telling me that I conducted an invalid experiment and I should try again. I fully expect the experiment to fail -- Kitz has spelt out the reasons in quite simple terms, above -- but as a scientist I must perform the experiment properly. :)
-
I just assumed that BT MSANs might not speak PTM, for whatever reason. I forgot, originally, about the fact that this is a non-BT MSAN/DSLAM.
-
PTM definitely wouldn't work on 20CN because it does not exist for ADSL1!
-
Maybe Im missing something, but I'm not quite sure how you are going to connect to an ATM DSLAM using PTM and without a PVC. :(
ADSL1 /2/2+ use ATM DSLAMs
BT uses VC-MUX (Virtual Circuit Multiplexing) on its DSLAMs although I think TT may use the older LCC which still needs a VCI
Layer 2 is 'dumb' routing - no IP addressing - hence why the need for a virtual circuit (PVC) and use of virtual paths.
Here in the UK when setting up a router with ATM we use VPI 0 and VCI 38.
--
FTTC uses IP DSLAMs. Still layer 2 routing but uses designated VLANs.
When setting up a PTM connection we have to input the VLAN info - see IEEE 802.1q (https://en.wikipedia.org/wiki/IEEE_802.1Q) which is ethernet specific.
As soon as you select PTM it should ask for VLAN info - See my setup guide here (http://www.kitz.co.uk/routers/zyxel_VMG8324-B10A_vdsl_setup.htm). Note also Openreach uses 802.1p which is a QoS extension for 802.1q. I think both BT and TT have to be set at 1 because of IPTV services.
--
The way you configure ATM and PTM are different.
An ATM DSLAM will be expecting the Virtual Circuit ID (VCI) to handshake, its not going to understand any IEEE 802.1x info.
The mode protocols are different and you cant mix and match from one protocol suite with bits from another.
Its kinda like asking an FTP client to be able to read HTTP traffic.
-
I would like to use the statement "It takes two to tango" as an analogy.
Let us assume that the "two" so referenced, above, each have a wide repertoire of dance steps and are equally matched in that respect. Let us further assume that numbers "one" and "two" come together to perform a dance. Number one attempts to performs a tango but number two attempts to perform a military two-step.
I think Weaver will appreciate the analogy.
The TalkTalk MSAN is configured only to use ATM for G.992.{1|3|5} modulation. (The preceding sentence is number one's tango.)
My CPE, a ZyXEL VMG1312-B10D, can be configured to use G.992.{1|3|5} modulation and, furthermore, for G.992.{3|5} modulation it can be configured to use PTM. (The preceding sentence is number two's military two-step.)
I finally repeated the experiment (see replies 3, 4, 6, 8, 10 & 15, above) under well defined conditions. The experiment, as predicted, failed. Synchronisation was readily achieved between the ATU-C and the ATU-R but no higher level data transfer was possible . . . as it takes two to tango. :)
-
Burakkucat was thinking about the U-interface in G.992.x terminology, the DSL link, its protocol stack options and the possible configurations of the two devices.
I was thinking about the V-interface, beyond the ATU-C, expecting it to be just as likely to fail because of config- or capabilities-incompatibility there.
But given the close ties between G.992.3 and VDSL2, I was prepared for a surprise if all the kit might be willing.
-
This all started from me grasping at straws as to why my HEC error counts disappeared one day, became "n/a", and never came back.
I wonder how your favourite ISP gets hold of this kind of status info, how many of the mechanisms are lurking in standards docs somewhere, how much is in manufacturers’ specs and how much is BT proprietary cunningness?