Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: Notes on the xdslcmd in Broadcom based modems  (Read 27126 times)

JustAnother

  • Member
  • **
  • Posts: 38
Notes on the xdslcmd in Broadcom based modems
« on: December 02, 2011, 11:59:19 AM »

Older thread that has been replaced with this one due to maxing out the initial post size.

I have recently gained a VDSL2 line, and courtesy of asbokid's work I have unlocked the modem and subsequently spent some time with it. One of the things I wanted a better understanding of was the stats available via '/bin/xdslcmd info', and rather than let my notes rot away I want to share them so that the next me coming along would not need to do the investigation work again.

If anyone knows better than this, please can they say (backed up with a source) and I will update this post.


For reference, the cabinet for my line is a few minutes walk away from my house (the BT technician did not know the distance), and the JSDU unit reported the maximum line synch at 36000 Kbit down, 10000 Kbit up – either it was provisioned on profile 17a or changed to that before I unlocked the modem.

Available Info Commands

Code: [Select]
xdslcmd info [--state] [--show] [--stats] [--SNR] [--QLN] [--Hlog] [--Hlin] [--HlinS] [--Bits]
[--pbParams] [--linediag] [--linediag1] [--reset] [--vendor] [--cfg]

xdslcmd info –state

This provides the most basic data available, which is included at the top of the output of all other stat commands:

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9106 Kbps, Downstream rate = 49912 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps

I have observed the following status values during testing (the states briefly mentioned here at the end):

Code: [Select]
Status: G.993 Started
Status: G.994 Training
Status: Showtime

Showtime indicates that training has been completed and the line is operating normally.

Retrain Reason: asbokid has come up with the following based off the available broadcom source code (re-training in general is 'optional and vendor proprietary' according to the standard, so the following is probably only valid for broadcom chipsets, for more detail see the asbo's post):

Code: [Select]
Loss Of Framing (not receiving valid frame) : re-train reason code of 2.
Loss Of Signal (not receiving signal) : re-train reason code of 4.
Loss Of Power : re-train reason code of 8.
Loss Of Signal Quality : re-train reason code of 16.
Loss Of Margin : re-train reason code of 32.

Max represents the maximum attainable rate the line is capable of under the current conditions, and Path 0 lists the rates the line is currently synched at. It appears that in order to use the max rates, you need to resynch with the DSLAM (there is a Seamless Rate Adaption option, but it is disabled by default and probably isn’t available even if it was enabled).

Path 0 refers to the fact that the firmware of the Openreach modem, properly known as the Huawei Echolife Home Gateway, supports multiple tagged VLANs  – 0 is the VLAN your normal connection is ran over and 1 is BT’s backdoor network.

‘It looks as though the “max attainable” figure is actually “max attainable at 6dB SNRM” thus it is possible for this figure to be lower than the current sync if the SNRM drifts below 6dB’ – source.

You can see my max downstream rate is far in excess of the rate I am synched at – this is the 40Mbit cap in action (the line is sold at 40/10Mbit).

xdslcmd info –show

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9124 Kbps, Downstream rate = 49912 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 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): 10.4 6.3
Attn(dB): 0.0 0.0
Pwr(dBm): 11.9 5.8

VDSL2 framing
Path 0
B: 239 223
M: 1 1
T: 64 35
R: 0 16
S: 0.1910 0.7805
L: 10054 2460
D: 1 1
I: 240 120
N: 240 240
Counters
Path 0
OHF: 26881481 1124041
OHFErr: 1492 140
RS: 0 1695887
RSCorr: 0 259
RSUnCorr: 0 0

Path 0
HEC: 4143 0
OCD: 0 0
LCD: 0 0
Total Cells: 2042409149 0
Data Cells: 114539597 0
Drop Cells: 0
Bit Errors: 0 0

ES: 409 130
SES: 4 0
UAS: 16 16
AS: 82459
Path 0
INP: 0.00 0.00
PER: 3.05 13.65
delay: 0.00 0.00
OR: 62.83 35.14
Bitswap: 3486 2599

Annex B: Suggestion that this represents a line that carries voice and broadband. Discussion is currently ongoing as to the exact detail of what this is - annex defines how the available tones are split between upload and download bins.

TPS-TC: Transport Protocol Specific Transmission Convergence sublayer.

The following single letter acronyms courtesy of npr (source pdf, see page 24):

B: Number of bytes in Mux Data Frame.
M: Number of Mux Data Frames in FEC Data Frame.
T: Mux Data Frames over sync bytes.
R: Number of check bytes in FEC Data Frame.
S: Ratio of FEC over PMD Data Frame length.
L: Number of bits in PMD Data Frame.
D; Interleave depth (1=fast path).

OHF and OHFErr: kitz says:
'Im guessing here, but Frame OverHeads?  These are a checksum byte to ensure the data is being transmitted/received properly, working in a similar way to HEC's or CRC's. DSL data frames (see bottom of page here) have checkbytes, and the OHFErr would then be the amount of errors detected and the data frame had to be retransmitted. They certainly appear to be some sort of frame counter.'
TODO – Anyone able to back this up with a source?

The following is also backed up by CT-5372 Multi-DSL Router User’s Manual (pdf) and the Kitz Router Line Stats - Errors article:

RS: Reed Solomon codes.

RSCorr: Data corrected by Reed Solomon codes.

RsUnCorr: Data uncorrected by RS codes, must be retransmitted

ES: Errored seconds. “An Errored Second is a second in which one or more coding violations occurred OR one or more loss of signal defects occurred.

Again, as with CRC I am not aware of any standard formula which would indicate whether a given level of ES is acceptable or unacceptable. Anything other than a near perfect line will give some level of ES error. On really bad lines the ES number can actually equal the total seconds i.e. every second of connection experienced a coding violation or loss of signal.

In many ways, in my opinion, errored seconds are a better indicator of a line that is struggling than CRC. Severely errored seconds give an additional quantification” – source.

SES: Severely errored seconds. “As the name suggests, a severely errored second is worse than an errored second. To be counted as errored only one event needs to occur. A severely errored second quantifies this. Typically a severely errored second is one where a threshold number of events is passed. I am not aware of a standard for this threshold and so each manufacturer may set their own threshold for what constitutes a severely errored second.” – source.

OCD: Number of out-of-cell Delineation errors.

LCD: Number of Loss of Cell Delineation errors.

UAS: Number of Unavailable Seconds (presumably when synch was lost with the DSLAM).

AS: Number of Available Seconds. UAS + AS  = system uptime (see Data Problems, Router Uptime VS Link Uptime).

INP: “Electrical appliances and installations at customer premises often generate short bursts of noise of relatively high amplitude. These bursts, called impulse noise, are electromagnetically coupled into the digital subscriber line, degrading performance and in some cases disrupting service. The ADSL2/plus standard introduced a parameter (impulse noise protection, INP) that allows operators to select the maximum impulse length that the system can correct. VDSL2 uses this same parameter. In effect, an INP value of between 2 and 16 can correct errors from noise impulses ranging from 250µs to 3.75ms in length.” – source.

PER: Packets in ERror.

Delay: The delay due to interleaving being applied on the line - recorded in microseconds (confirmed by kitz, see Kitz interleaving article) - differing levels of interleaving (and therefore delay) can be set by the service provider so this isn't just a set value. As I have no interleaving, this is currently 0.

OR: TODO: Unknown.

Bitswap: Changing the bit loading of the bins used when a bin’s usablility (SNR) falls below its original bit loading. Other bins that are not running at full capacity can take on the extra data – see kitz’s excellent article on how *DSL works.

xdslcmd info –stats

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9083 Kbps, Downstream rate = 49696 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 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): 10.3 6.2
Attn(dB): 0.0 0.0
Pwr(dBm): 11.9 5.8

VDSL2 framing
Path 0
B: 239 223
M: 1 1
T: 64 35
R: 0 16
S: 0.1910 0.7805
L: 10054 2460
D: 1 1
I: 240 120
N: 240 240

Counters
Path 0
OHF: 107332063 766680
OHFErr: 5712 584
RS: 0 3712854
RSCorr: 0 1029
RSUnCorr: 0 0

Path 0
HEC: 10580 0
OCD: 0 0
LCD: 0 0
Total Cells: 3828791842 0
Data Cells: 240466458 0
Drop Cells: 0
Bit Errors: 0 0

ES: 1738 530
SES: 4 0
UAS: 16 16
AS: 329237

Path 0
INP: 0.00 0.00
PER: 3.05 13.65
delay: 0.00 0.00
OR: 62.83 35.14

Bitswap: 8481 8801

Total time = 1 days 19 hours 27 min 34 sec
FEC: 0 0
CRC: 5712 0
ES: 1738 530
SES: 4 0
UAS: 16 16
LOS: 0 0
LOF: 0 0

Latest 15 minutes time = 12 min 34 sec
FEC: 0 0
CRC: 6 0
ES: 5 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 137 0
ES: 6 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

Latest 1 day time = 19 hours 27 min 34 sec
FEC: 0 0
CRC: 2432 0
ES: 483 119
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 793 0
ES: 391 142
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

Since Link time = 3 days 19 hours 27 min 17 sec
FEC: 0 1029
CRC: 5712 584
ES: 1738 530
SES: 4 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

LOS: Loss of signal (i.e. the line goes dead).

LOF: Loss of frame (ATM framing).

Total time: Presumably system uptime, however fails badly as the day count never passes 1 (...) - see Data Problems, Router Uptime VS Link Uptime.

Since Link time: Presumably time since the current synch to the DSLAM started.

xdslcmd info –SNR

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9091 Kbps, Downstream rate = 49696 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
Tone number SNR
0 0.0000
1 0.0000
< and so on for the thousands of [url=http://www.kitz.co.uk/adsl/adsl_technology.htm]tones/bins[/url] >

xdslcmd info –QLN

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9083 Kbps, Downstream rate = 49696 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
Tone number QLN
0 -160.0000
1 -160.0000

< and so on for thousands of [url=http://www.kitz.co.uk/adsl/adsl_technology.htm]tones/bins[/url] >

QLN: Quiet Line Noise (see Measuring Line Characteristics on the Huawei).

xdslcmd info –Hlog

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9098 Kbps, Downstream rate = 49576 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
Tone number Hlog
0 -96.0000
1 -96.0000
< and so on for thousands of [url=http://www.kitz.co.uk/adsl/adsl_technology.htm]tones/bins[/url] >

Hlog: Logarithmic channel characteristic function Hlog(f) (see Measuring Line Characteristics on the Huawei).

xdslcmd info –Hlin

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9095 Kbps, Downstream rate = 49576 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
Hlin scale factor: DS = 0 US = 0
Tone number Hlin
0 0 0
1 0 0
2 0 0
3 0 0
< and so on for thousands of [url=http://www.kitz.co.uk/adsl/adsl_technology.htm]tones/bins[/url] >

Hlin: Hlin(f) is a format providing complex values in linear scale (as compared to Hlog which is logarithmic – see Measuring Line Characteristics on the Huawei).

xdslcmd info –HlinS

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9098 Kbps, Downstream rate = 49696 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
0 0.000000e+00 0.000000e+00
1 0.000000e+00 0.000000e+00
< and so on for thousands of [url=http://www.kitz.co.uk/adsl/adsl_technology.htm]tones/bins[/url] >

HlinS: This should be a scaling factor applied to Hlin (see mention of the scaling factor in Measuring Line Characteristics on the Huawei).

xdslcmd info –Bits

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9106 Kbps, Downstream rate = 49576 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
Tone number Bit Allocation
0 0
1 0
< and so on for thousands of [url=http://www.kitz.co.uk/adsl/adsl_technology.htm]tones/bins[/url] >

Bit allocation per tone/bin (see Kitz ADSL Technology and DMT).

xdslcmd info –pbParams

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9098 Kbps, Downstream rate = 49696 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 9098 kbps 49696 kbps
Actual Aggregate Tx Power: 5.8 dBm 11.9 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 5.9 32.4 48.9 N/A 15.2 40.5 63.0
Signal Attenuation(dB): 10.9 31.5 48.0 N/A 15.2 40.5 63.0
SNR Margin(dB): 6.1 6.3 6.2 N/A 10.2 10.4 0.0
TX Power(dBm): -4.1 -12.7 5.3 N/A 9.7 7.8 -15.5

This lists the bins used in the band plan (numbers detailed in brackets) that correspond to the frequency bands used by the current VDSL2 profile (17a for me). With profile 8c, two bands are used for upload and download data. See Kitz for details about attenuation and SNR.

N/A indicates that the modem/DSLAM(?) decided that the band was too attentuated to even try to use.

xdslcmd info –linediag

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9083 Kbps, Downstream rate = 49576 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
Down Up
SNRM(dB): 10.3 6.2
LATN(dB): 0.0 0.0
SATN(dB): 0.0 0.0
TxPwr(dBm): 11.9 5.8
ATTNDR(Kbps): 49576 9083
Tone number SNR
0 0.0000
1 0.0000
< and so on for thousands of [url=http://www.kitz.co.uk/adsl/adsl_technology.htm]tones/bins[/url] >

xdslcmd info –linediag1

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9080 Kbps, Downstream rate = 49696 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 9080 kbps 49696 kbps
Actual Aggregate Tx Power: 5.8 dBm 11.9 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 5.9 32.4 48.9 N/A 15.2 40.5 63.0
Signal Attenuation(dB): 10.9 31.6 48.0 N/A 15.2 40.5 63.0
SNR Margin(dB): 6.3 6.2 6.2 N/A 10.2 10.4 0.0
Line 0 DS HLOG (dB) (grouped by 8 tones):
< data omitted >

Line 0 US HLOG (dB) (grouped by 8 tones):
< data omitted >

Line 0 DS QLN (dBm/Hz) (grouped by 8 tones):
< data omitted >

Line 0 US QLN (dBm/Hz) (grouped by 8 tones):
< data omitted >

Line 0 DS SNR (dB) (grouped by 8 tones):
< data omitted >

Line 0 US SNR (dB) (grouped by 8 tones):
< data omitted >

Line 0 DS HLIN (grouped by 8 tones):
< data omitted >

Line 0 US HLIN (grouped by 8 tones):
< data omitted >

xdslcmd info –vendor

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9109 Kbps, Downstream rate = 49576 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
ChipSet Vendor Id: BDCM:0xa1b7
ChipSet VersionNumber: 0xa1b7
ChipSet SerialNumber:

Admin - Slightly edited topic title
« Last Edit: May 13, 2017, 09:07:52 PM by kitz »
Logged

JustAnother

  • Member
  • **
  • Posts: 38

xdslcmd info –cfg

Code: [Select]
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 9098 Kbps, Downstream rate = 49696 Kbps
Path: 0, Upstream rate = 9113 Kbps, Downstream rate = 39997 Kbps
adslTrainingMarginQ4: -1
adslShowtimeMarginQ4: -1
adslLOMTimeThldSec: -1
adslDemodCapMask: 0090447a
adslDemodCapValue: 0010447a
adsl2Param: 00000000
adslPwmSyncClockFreq: 0
adslHsModeSwitchTime: 0
adslDemodCap2Mask: 00540200
adslDemodCap2Value: 00540200
vdslParam: 007f00ff
vdslParam1: 00000000
xdslAuxFeaturesMask: 00000003
xdslAuxFeaturesValue: 00000003
vdslCfgFlagsMask: 00000000
vdslCfgFlagsValue: 00000000

xdslcmd profile –show

Code: [Select]
Modulations:
G.Dmt Enabled
G.lite Enabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Enabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Enabled
VDSL2 profiles:
8a Enabled
8b Enabled
8c Enabled
8d Enabled
12a Enabled
12b Enabled
17a Enabled
30a Enabled
US0 Enabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra Off
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) Off/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: On
SOS: On
Training Margin(Q4 in dB): -1(DEFAULT)

sra: Seamless Rate Adaption as mentioned before.

trellis: Trellis Coded Modulation.

sesdrop: Some sort of functionality to stop all error correction stuff in order to reduce latency on the line? See Think Broadband thread. TODO: Anyone able to confirm what this is?

TODO: What are the rest of these for?

Data Problems

CRC And FEC Data

It appears the code behind the stats as obtained via xdslcmd and/or the web interface is either incomplete or poorly made. Bald_Eagle has highlighted a discrepancy in what exact data is returned for CRC and FECs from the sources:

From the web interface:

Code: [Select]
DS CRC errors 54391
DS FEC errors 1349
DS HEC errors 16063

From xdslcmd info --stats:

Code: [Select]
DS CRC errors 1349           (reported as FEC errors above & also reported as OHFerr in xdslcmd info --stats)
DS FEC errors 1377279      (No idea what this relates to, other than same value as RSCorr in xdslcmd info --stats)

FEC and CRC errors appear to be flipped around and some data is unaccountable.

Router Uptime VS Link Uptime

Bald_Eagle has also shown that the way the router reports the total (system) uptime and link (connection) uptime is suspect - selected output from my 'xdslcmd info --stats':

Code: [Select]
UAS:        17        17
AS:        251975

Total time = 1 days 21 hours 59 min 52 sec

Since Link time = 2 days 21 hours 59 min 33 sec

Clearly the link time cannot be greater than the time the system was up for. rhone has pointed out that the day count never goes past 1 on the Netgear DG834GT, and checking now I can indeed see that this is the case with this router! I enjoy the fact a machine processing ~5MB/Sec of data cannot count.
« Last Edit: December 23, 2011, 06:29:26 PM by JustAnother »
Logged

JustAnother

  • Member
  • **
  • Posts: 38

See this post below info on xdslcmd --help

http://forum.kitz.co.uk/index.php/topic,10289.msg317080.html#msg317080


admin - added link for xdslcmd --help
« Last Edit: May 13, 2017, 09:10:17 PM by kitz »
Logged

JustAnother

  • Member
  • **
  • Posts: 38

Reserved post 2.
Logged

JustAnother

  • Member
  • **
  • Posts: 38

Reserved post 3.
Logged

JustAnother

  • Member
  • **
  • Posts: 38

Reserved post 4.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 29903
  • Trinity: Most guys do.
    • http://www.kitz.co.uk

Very interesting article thank you for posting

>> Annex B:

That has me puzzled because thats the standard for adsl over ISDN and used in certain countries, whereas I thought we used Annex A / Annex M in the uk.

Out of curiousity does the standard firmware connect using annex B or is it just on the unlocked firmware?  My understanding is that the annex defines the mapping available for the downstream/upstream tones for use.  Annex A defines which tones are available for the upstream reserving those needed for POTS.  Im assuming if the router is set at Annex B, yet the standard used by BT is Annex A, the MSAN will just over-ride this.



>> OHF and OHFErr: TODO – Unknown.

Im guessing here, but Frame OverHeads?  These are a checksum byte to ensure the data is being transmitted/recieved properly, working in a similar way to HEC's or CRC's.
DSL data frames (see bottom of page here ) have checkbytes, and the OHFErr would then be the amount of errors detected and the data frame had to be retransmitted.
They certainly appear to be some sort of frame counter.


>> Delay: I think this is the delay introducted by interleaving on the line.

See http://www.kitz.co.uk/adsl/interleaving.htm

Quote
Interleave Delay defines the mapping (relative spacing) between subsequent input bytes at the interleave input and their placement in the bit stream at the interleave output.

>> As the interleaving level can be differed,

The maximum interleave delay is something that can be configured by the SP* on the MSAN.
(SP being the owner of the MSAN say Be/Sky etc)


btw.. not sure if youve seen this  http://www.kitz.co.uk/adsl/linestats_errors.htm which shows some of the common counters such as RS and RSCorr UAS etc
« Last Edit: December 19, 2011, 09:41:42 AM by kitz »
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2719

Hi kitz,

Very interesting article thank you for posting

>> Annex B:

That has me puzzled because thats the standard for adsl over ISDN and used in certain countries, whereas I thought we used Annex A / Annex M in the uk.

Out of curiousity does the standard firmware connect using annex B or is it just on the unlocked firmware?  My understanding is that the annex defines the mapping available for the downstream/upstream tones for use.  Annex A defines which tones are available for the upstream reserving those needed for POTS.  Im assuming if the router is set at Annex B, yet the standard used by BT is Annex A, the MSAN will just over-ride this.




Here's a snippet from my unlocked modem:-

Code: [Select]
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 6210 Kbps, Downstream rate = 31968 Kbps
Path: 0, Upstream rate = 6311 Kbps, Downstream rate = 27189 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): 3.7 5.5
Attn(dB): 0.0 0.0
Pwr(dBm): 12.3 6.2
VDSL2 framing
Path 0
B: 31 191
M: 1 1
T: 64 40
R: 12 12
S: 0.0374 0.9657
L: 9401 1690
D: 1743 1
I: 44 102
N: 44 204
Counters
Path 0
OHF: 22277373 1375498
OHFErr: 3274 217
RS: 4259640857 2267123
RSCorr: 3490669 947
RSUnCorr: 363316 0

Path 0
HEC: 70735 0


Elsewhere, this is mentioned:-

G.992.3_Annex_K_PTM

Does that help at all?


Paul.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 29903
  • Trinity: Most guys do.
    • http://www.kitz.co.uk

Another Annex B

>>> G.992.3_Annex_K_PTM

Where was that???     :o   Now that is VERY strange - because G.992.3 is actually adsl2!!  ???
VDSL should be showing as G993.x


Basically the G number defines the type of DSL, whilst the Annex defines the spectral mask in use.
As I mentioned earlier, its the Annex which maps out which tones can be used for (DMT) bitloading and these masks set the maximum bits which can be used in each particular bin (hence why we sometimes see curved bit loading graphs particulary on the upstream and lower end of the downstream).

This is a typical example of an Annex A Mask


- Note the inverted 'U' shape for bitloading

An Annex M Mask simply shunts the lower downstream tones (those that you see with not as much bit loading) over to be available for upstream.  These crossover tones dont get the full bitloading to keep downstream v upstream crosstalk between the 2 technologies to a minimum on the MSAN.

TBH I dont know much about Annex B as I didnt think it was in use in the UK (but then again I dont have any personal experience with VDSL), but off the top of my head it gives some of the POTS reserved tones in Annex A over to the upstream on Annex B
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Bald_Eagle1

  • Helpful
  • Kitizen
  • *
  • Posts: 2719

Hi kitz,

Another Annex B

>>> G.992.3_Annex_K_PTM

Where was that???     :o   Now that is VERY strange - because G.992.3 is actually adsl2!!  ???
VDSL should be showing as G993.x


It comes from the modem's URL http://192.168.1.1/html/status/xdslStatus.asp

The full details are:-

Code: [Select]
var DSLCfg = new Array(newstDsl"InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig",
"Up","VDSL2","","6311","27189","0","0","6348","32044","57","38","0","0","62","123","G.992.3_Annex_K_PTM"),null);

var DSLStats = new Array(new stStats("InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.Stats.Showtime",
"113126","0","585276","0","6252","290","0","0","0","0","0","0"),null); var DslUpTime = "117811";

var time = 0;


It is quite possible that the modem is displaying G.992.3 incorrectly, instead of G.993.2.
It does display some other data back-to-front or a bit "mixed up".

It would appear that a number of bugs may be present in the Broadcom software. The general impression from those that understand these things is that it is rather poorly written.


I see that ITU-T G993.2 does cover "Very high speed digital subscriber line transceivers 2 (VDSL2)"
&
ITU-T G.992.3 covers "Asymmetric Digital Subscriber Line (ADSL) transceivers 2 (ADSL2)"


Paul

EDIT:-
BT's variant of VDSL2 does "optionally" use upstream band U0 (tones 0 to 95).
My understanding is that that US band is used in the UK to assist somewhat with US over longer line lengths.
& some of that actually overlaps with DS band D1 (tones 32 to 859).

I have a "longer" line length, & I see quite a fair amount of bitloading at these lower frequency bands (see attached graph) The blue sections show the "shared" tones


« Last Edit: December 19, 2011, 05:41:05 PM by Bald_Eagle1 »
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 29903
  • Trinity: Most guys do.
    • http://www.kitz.co.uk

Yep G.993.1 is VDSL and G.993.2 is VDSL2.

I think you may be right about it perhaps being a mixed up display.  As regards to Annex K, I'd not even heard of that before.

Annex B shocked me a bit because I'd not been aware it was in use in the UK, Ive been a bit out of touch in the past year, so I cant really comment if they are using it or not and I need to get myself back up to speed at some point. 

If you are seeing bit loading at the lower frequencies (below 25kHz - Bin 7) then this would indicate some other Annex mask in use.   

>> My understanding is that that US band is used in the UK to assist somewhat with US over longer line lengths & some of that actually overlaps with DS band D1 (tones 32 to 859).

I could be wrong, but that sounds like Annex_L

-----

I need to do some digging, but not tonight, its taken me about 2 hours to type just this as Ive had to rush my cat to the vets tonight where they did a quick emergency op. Im up and down like a yoyo atm, as he's not coping very well with one of those cone collar thingies, and seems to need constant supervision.  Everytime I think he's settled and I go to sit back at the PC, I'll then hear him crash into something.  ::)
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

JustAnother

  • Member
  • **
  • Posts: 38

Merry Christmas, ha, didn't expect the founder to post here!

I have updated the post - as the correct interpretation of Annex B has yet to be decided I've just linked to the first discussion post.
Logged

johnwigley

  • Just arrived
  • *
  • Posts: 9
SOLVED: Line stats on SAME INTERFACE / SINGLE CABLE
« Reply #12 on: June 27, 2015, 02:20:20 PM »

Logged

loadbang

  • Just arrived
  • *
  • Posts: 8
Re: Notes on xdslcmd stats for Huawei Echolife Home Gateway/Openreach VDSL2 modem
« Reply #13 on: September 14, 2015, 02:20:57 PM »

I'm having a problem with telnet not printing. All I get when a type a command is a newline with "^". Tried OS X, Debian, and Solaris.
Logged

JustAnother

  • Member
  • **
  • Posts: 38
Re: Notes on xdslcmd stats for Huawei Echolife Home Gateway/Openreach VDSL2 modem
« Reply #14 on: September 14, 2015, 02:28:07 PM »

For reference I've been using a Billion modem for some time now so I won't be able to help (outside of saying things Just Worked for considerable time under Debian Testing).
Logged
Pages: [1] 2