Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Chrysalis]

yeah nice tests thanks, the only unknown now is if dlm takes the loss of power counter into account, but given openreach documentation, my guess is it does.

[snadge]

thanks for replies

I meant VDSL modem and turning them off at nights when going to bed....sorry should have made that clear - i would have thought DLM is set to ignore loss of sync if its late in evening and connects again 6am onwards...indicative of owner going to bed?


ASBOKID - how the heck do you get all the info from the DSLAM? - impressed!! 

[burakkucat]

ASBOKID - how the heck do you get all the info from the DSLAM? - impressed!! 

May I suggest that owning the DSLAM allows one to connect to its various service ports and to enter its configuration modes. 

[snadge]

ASBOKID - how the heck do you get all the info from the DSLAM? - impressed!! 

May I suggest that owning the DSLAM allows one to connect to its various service ports and to enter its configuration modes. 

so Asbo actually has a DSLAM in-house hehe??  thats dedication for you

[asbokid]

Yeah, Our Wayne and his mate Fingers of Feltham lifted it for us!  Only joking!     Huawei vendors were selling them for £70 on Taobao, to clear stock when Huawei started shipping a replacement central control unit. Though SFAIK this one is the same as BT has been using (with a CCUB controller).

Quite useful for hacking. Just using it now to develop some code for OpenWrt on the ECI /r VDSL2 modem.  It would be impossible to do this work with the number of errors and re-syncs I've caused (deliberately injecting noise onto the line). On a live Openreach circuit, DLM would have down-profiled it to just a few bits per seconds!

cheers, a

edit: finally getting some error counters out of the ECI now.  Not sure what they mean, so just checking them against the counters held by the DSLAM.

Code: [Select]

CPE Chipset:            Lantiq-VRx:5.4.8.6.1.6
CO Chipset:             BDCM:v10.07.26
Line State:             UP [0x801: showtime_tc_sync]
Attain Data Rate:       28848 Kbps / 50000 bps
Actual Data Rate:       28832 Kbps / 944000 bps
Interleave Delay:       0.0 ms / 0.0 ms
Impulse Noise Prot:     0.0 sym / 0.1 sym
Line Attenuation:       44.8 dB / 0.0 dB
Signal Attenuation:     40.2 dB / 0.0 dB
Noise Margin:           5.1 dB / 1.7 dB
Transmit Power:         13.2 dBm / 4.0 dBm
Line Uptime:            8m 57s
Chan FEC Errors:        56 / 8709
Chan Code Violations:   1 / 128
Path CRC Errors:        0 / 1460
Path Code Violations:   0 / 100941


[burakkucat]

so Asbo actually has a DSLAM in-house hehe??  thats dedication for you

Yes, indeed.

I seem to recall him telling me that the MA5616 was a nice fit in the shower cubicle and that the waste pipe was a useful duct through which to route a fibre-optic feed! 

Here is a new Huawei SmartAX MA5616, available as a 'Buy It Now' item on eBay.

[snadge]

haha - I was thinking that about the errors/DLM aswell asbo 

[asbokid]

haha - I was thinking that about the errors/DLM aswell asbo 

Yes, it's useful looking at both ends of a connection, particularly for checking error rates!

From studying error counts at the DSLAM end, it's evident that the HG612 doesn't record RsUnCorr(ectables) properly.  It records errors okay with ADSL connections, but not with VDSL connections. In the upstream direction of a VDSL2 connection, RsUncorr errors are not recorded at all.

E.g. in the screenshots below, the errors are recorded at both DSLAM and CPE as 300mV amplitude Gaussian noise is injected into the line.  The noise causes a splurge of channel/path errors including, according to the DSLAM, 208 RsUncorr errors in the upstream. These are labelled as "uncorrectable blocks". Yet the HG612 doesn't record any of them.  Hmm... And god knows where its figure of 842 HEC errors comes from. 

cheers, a

[Bald_Eagle1]

From studying error counts at the DSLAM end, it's evident that the HG612 doesn't record RsUnCorr(ectables) properly.  It records errors okay with ADSL connections, but not with VDSL connections. In the upstream direction of a VDSL2 connection, RsUncorr errors are not recorded at all.

Can you test this again, with DS interleaving on at say, a depth of 400 or 500 and US Interleaving on at some depth?

I saw downstream RSUnCorr counts when my VDSL2 connection had DS Interleaving at a depth of around 400 or so, but no upstream counts (possibly because upstream Interleaving was OFF):-

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 5108 Kbps, Downstream rate = 27200 Kbps
Path: 0, Upstream rate = 5079 Kbps, Downstream rate = 23567 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.0 6.2
Attn(dB): 0.0 0.0
Pwr(dBm): 13.0 6.3
VDSL2 framing
Path 0
B: 63 159
M: 1 1
T: 60 36
R: 16 14
S: 0.0864 0.9986
L: 7409 1394
D: 373 1
I: 80 87
N: 80 174
Counters
Path 0
OHF: 146964063 343224
OHFErr: 29345 144
RS: 683727268 3391028
RSCorr: 18880457 416
RSUnCorr: 1221537 0



Now that my connection is strangely on fastpath, RSUnCorr counts are zero for both DS & US:-

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 4205 Kbps, Downstream rate = 21232 Kbps
Path: 0, Upstream rate = 4563 Kbps, Downstream rate = 20209 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.7 5.4
Attn(dB): 0.0 0.0
Pwr(dBm): 12.0 6.3
VDSL2 framing
Path 0
B: 239 143
M: 1 1
T: 57 34
R: 0 12
S: 0.3777 1.0000
L: 5084 1248
D: 1 1
I: 240 78
N: 240 156
Counters
Path 0
OHF: 107465258 599047
OHFErr: 21311 69
RS: 0 3154280
RSCorr: 0 62
RSUnCorr: 0 0




Was Interleaving ON at any depth on all the ADSL connection(s) you have examined?

I believe this is an example from your own connection (DS Interleaving depth of 64 & US OFF):-

Code: [Select]

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 8000
Max: Upstream rate = 1200 Kbps, Downstream rate = 21856 Kbps
Path: 0, Upstream rate = 1020 Kbps, Downstream rate = 19944 Kbps

Link Power State: L0
Mode: ADSL2+
TPS-TC: ATM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 2.4 11.9
Attn(dB): 18.5 9.7
Pwr(dBm): 19.3 12.3
ADSL2 framing
Path 0
MSGc: 59 10
B: 123 145
M: 2 1
T: 5 1
R: 6 0
S: 0.3972 4.5447
L: 5115 257
D: 64 1
Counters
Path 0
SF: 6898534 586924
SFErr: 2953 16
RS: 1121011482 0
RSCorr: 9065728 0
RSUnCorr: 60746 0


[asbokid]

From studying error counts at the DSLAM end, it's evident that the HG612 doesn't record RsUnCorr(ectables) properly.  It records errors okay with ADSL connections, but not with VDSL connections. In the upstream direction of a VDSL2 connection, RsUncorr errors are not recorded at all.

Can you test this again, with DS interleaving on at say, a depth of 400 or 500 and US Interleaving on at some depth?

I was just saying to Colin that this would be a useful test.  I will have a look at setting up the experiment. Interleaving isn't unfortunately configurable to the extent of setting the exact depth. Not even by DLM.

The Huawei DSLAM has a channel-profile parameter that allows the *maximum* interleaved *delay* to be set (and the inter-related *minimum* number of symbols to be protected by INP) but whether or not that maximum is fully utilised, or just a fraction of it, is up to the DSLAM.

So we can create a maximum of, say, 8ms delay in each direction, but the algorithm in the DSLAM will only increase the interleaver depth as much as needed, presumable to try and satisfy some BER, as well as keeping within that delay limit.

I saw downstream RSUnCorr counts when my VDSL2 connection had DS Interleaving at a depth of around 400 or so, but no upstream counts (possibly because upstream Interleaving was OFF):-

The DSLAM does appear to be recording *upstream* uncorrectable errors that the HG612 doesn't record. From a quick google it looks like it's a common issue with this and other Broadcom 6368 devices.

Interleaving and Forward Error Correction are not synonymous though.  It's possible (maybe normal practice) to still use FEC without interleaving.   The reverse isn't true though.  So setting it to fastpath could still see FEC (RSCorr / RSUnCorr) errors reported.

cheers, a

[Bald_Eagle1]

Interleaving and Forward Error Correction are not synonymous though.  It's possible (maybe normal practice) to still use FEC without interleaving.   The reverse isn't true though.  So setting it to fastpath could still see FEC (RSCorr / RSUnCorr) errors reported.

Ah, that could explain why I still see a small number of US RSCorr errors, even though DS & US Interleaving is OFF, with INP & delay at zero.

Code: [Select]

Counters
Path 0
OHF: 107465258 599047
OHFErr: 21311 69
RS: 0 3154280
RSCorr: 0 62
RSUnCorr: 0 0

Path 0
HEC: 50030 0
OCD: 0 0
LCD: 0 0
Total Cells: 1055279342 0
Data Cells: 80880670 0
Drop Cells: 0
Bit Errors: 0 0

ES: 26064 482
SES: 392 0
UAS: 974 974
AS: 580611

Path 0
INP: 0.00 0.00
PER: 5.38 17.00
delay: 0.00 0.00
OR: 47.56 27.29


[asbokid]

Forward Error Correction is presumably disabled when the Framing Parameter 'R' (the number of redundancy bytes in the RS codeword) is set to zero.

Here, for example, R is zero (bytes) in the downstream, and 16 in the upstream. 

Consequently no data is being passed to the RS decoder by the CPE modem. This is confirmed by the zero in the downstream column of the RS row.

Code: [Select]

VDSL2 framing
Path 0
B: 239 237
M: 1 1
T: 23 45
R: 0 16
S: 0.0955 0.3782
L: 20104 5373
D: 1 1
I: 240 127
N: 240 254
Counters
Path 0
OHF: 123346 47730
OHFErr: 0 0
RS: 0 2147351
RSCorr: 0 0
RSUnCorr: 0 0
..
Path 0
INP: 0.00 0.00
PER: 1.64 4.25
delay: 0.00 0.00
OR: 116.54 60.17
..

cheers, a

Edit: from an earlier post:

[snadge]

interesting finds then Asbo...

other than the user not being able to read the errors....are there any other repercussions of the 6368 chipset not recording these stats?

[asbokid]

Hi Snadge, the DSLAM has the error counts, so no biggie in terms of VDSL2 performance. Not sure why it's omitted.

cheers, a