Print

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

[Ixel]

Yeah WWWombat, you're right - G.998.4 is the real name for G.INP. I guess most people will still call it G.INP instead of that though as it's easier to remember than numbers I guess.

I too have had FEC once or twice while being fastpath (on downstream), and get FEC on the upstream. It seems to have happened here when I have had a high SNRM (e.g. at least around 14.0 dB or higher) - obviously no G.INP/G.998.4 at the time.

[Bald_Eagle1]

It'd be interesting to see what the values are for "INP" (and INPrein, if it is shown), "delay" and "R" when the "FEC errors without interleaving" scenario is happening downstream.

These are mine (quite low FEC but D = 1 for DS & US):-

Code: [Select]


D: 1 1

R: 16 12
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 4.15 17.25
OR: 61.63 26.88
AgR: 22460.42 4939.47


[NewtronStar]

I see you are getting ready for G.INP though when it hit's your line you won't even notice the change and I suspect the same will happen when vectoring goe's live it's my belief your putting to much faith into the two different OpenReach technology's (your waiting for the eureka moment)

It may be more subtle than you think it should be on your line 

[Chrysalis]

rizla they would not have to increase max speed, but I agree the likely reason for vectoring delays is due to accounting.  From what BS posted the other day, it would seem vectoring is going to happen for huawei cabinets, as they just need an addon card but not for ECI which would need entire dslam replacing.

[Ixel]

That'll be a pain, ECI being excluded from vectoring (for an unknown time, assuming if they ever consider their users stuck on an ECI DSLAM).

[burakkucat]

As far as I am aware, the Huawei cabinets are fitted with either a SmartAX MA5603 or a SmartAX MA5616 MSANs and the ECI cabinets are fitted with a Hi-FOCuS Mini-Shelf M41 MSANs. (They are all MSANs but are just configured to be used as basic DSLAMs.)

A MA5603 equipped cabinet will just require the fitting of a vectoring engine card into the relevant slot of the backplane.

A MA5616 equipped cabinet will require the fitting of an expansion card-cage and backplane thus allowing a vectoring engine card to be installed.

In the case of a M41 equipped cabinet the line card(s) can be configured to support vectoring (I believe Kitz understands the process as "on-card vectoring"). The alternative would be to remove the Mini-Shelf M41 and fit a Vectoring-Shelf V41 in its place. Once the cabinet has been upgraded, a vectoring engine card can then be inserted into the appropriate slot of the backplane.

[Chrysalis]

so the ECI website is wrong where it doesnt state it supports vectoring? Although vectoring at a card instead of node level can be ineffective if noisy pairs are on different cards.

[Ixel]

Just noticed two people inside the fibre cab over the road with a lot of equipment, I wonder what they're up to - can only assume it's possibly some upgrade work maybe ?

(Cabinet is ECI)

[renluop]

Just noticed two people inside the fibre cab over the road with a lot of equipment, I wonder what they're up to - can only assume it's possibly some upgrade work maybe ?

(Cabinet is ECI)

My! They must be getting up close and personal, and wanting to produce something.

[Ixel]

Just noticed two people inside the fibre cab over the road with a lot of equipment, I wonder what they're up to - can only assume it's possibly some upgrade work maybe ?

(Cabinet is ECI)

My! They must be getting up close and personal, and wanting to produce something.

Haha, I can only hope that it might be preliminary work for vectoring later on (or if what BS's limited info gave an indication of a while ago, that vectoring may start rolling out from February). I'm highly doubtful it is related to that though.

[WWWombat]

Code: [Select]


D: 1 1

R: 16 12
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0


I should have asked for N as well 

The "R" value suggests that you have FEC protection running downstream as well as upstream, using R parity bytes in each block of N bytes. That probably explains the presence of FEC errors, but doesn't give us any indication of why the modem has chosen to do this. In your case, it doesn't look like you have an excess of capacity ... unless you are banded. I don't recall you being banded though.

[Bald_Eagle1]

Full stats:-

Code: [Select]

xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 5077 Kbps, Downstream rate = 23916 Kbps
Bearer: 0, Upstream rate = 4912 Kbps, Downstream rate = 22399 Kbps

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1200)
DS: (33,859) (1216,1764)
  VDSL Port Details   Upstream   Downstream
Attainable Net Data Rate:      5077 kbps     23916 kbps
Actual Aggregate Tx Power:        6.6 dBm      12.7 dBm
====================================================================================
  VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
  Line Attenuation(dB): 8.0 52.9   N/A   N/A   N/A 21.6 65.0   N/A
Signal Attenuation(dB): 8.0 52.0   N/A   N/A   N/A 30.3 64.7   N/A
SNR Margin(dB): 6.7 6.4   N/A   N/A   N/A 7.1 7.1   N/A
TX Power(dBm): -1.5 5.9   N/A   N/A   N/A 11.6 6.3   N/A




Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 5077 Kbps, Downstream rate = 23916 Kbps
Bearer: 0, Upstream rate = 4912 Kbps, Downstream rate = 22399 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): 7.1 6.5
Attn(dB): 24.4 0.0
Pwr(dBm): 12.7 6.6
VDSL2 framing
Bearer 0
MSGc: 26 52
B: 237 143
M: 1 1
T: 49 37
R: 16 12
S: 0.3378 0.9293
L: 6016 1343
D: 1 1
I: 254 78
N: 254 156
Counters
Bearer 0
OHF: 472100263 865751
OHFErr: 48715 385
RS: 1658064624 693178
RSCorr: 3436839 978
RSUnCorr: 250118 0

Bearer 0
HEC: 213145 0
OCD: 15868 0
LCD: 15868 0
Total Cells: 2837159271 0
Data Cells: 541078294 0
Drop Cells: 0
Bit Errors: 0 0

ES: 23825 357
SES: 63 0
UAS: 22 22
AS: 1961038

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 4.15 17.25
OR: 61.63 26.88
AgR: 22460.42 4939.47

Bitswap: 1267638/1267643 5652/5660

Total time = 1 days 16 hours 44 min 20 sec
FEC: 3436839 978
CRC: 48715 385
ES: 23825 357
SES: 63 0
UAS: 22 22
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 14 min 20 sec
FEC: 34 0
CRC: 17 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: 17 0
CRC: 10 0
ES: 8 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 16 hours 44 min 20 sec
FEC: 3322 22
CRC: 1019 11
ES: 683 11
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 7158 11
CRC: 1518 9
ES: 992 8
SES: 1 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 22 days 16 hours 43 min 57 sec
FEC: 3436839 978
CRC: 48715 385
ES: 23825 357
SES: 63 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0


FWIW, my connection has managed to sustain DS fastpath with lowish FEC counts since 26th August 2014.
Prior to that it could only sustain a few days on fastpath (following DLM resets) before having Interleaving applied at a depths of around 350 to 400, with INP at 3.00 & delay at 8.


The slight amount of spare DS SNRM comes with reduced temperatures at this time of year as Line & Signal Attenuation always increase in summer & decrease in winter, certainly on my connection:-

[WWWombat]

I don't think I've checked attenuation graphs like that over the course of a year. Interesting!

Looking at the full stats, I can see:

Downstream, the FEC has been applied at the rate of 16/254, or about 6% - and that must be about the smallest overhead it could have. The impact is pretty effective: 93% of RS problems are being corrected - only 7% go on to trigger full CRC faults. I'm trying to figure out *why* FEC is being so effective without interleaving present...

As your daily ES count seems to reach 1,000, it seems like this FEC setting is doing a good job at keeping you under the ES thresholds for further intervention.

Obviously INP and "delay" are still set to zero, so DLM has not asked for FEC (using those parameters, anyway); I think I might have to investigate what some of the other parameters mean (PER, OR and AgR are probably good starting points).

Upstream has a small surprise... that the value of I and N are not the same. I should be a sub-multiple of N (which is true here), but it only has real meaning when interleaving is turned on (I is the 2nd dimension of the interleaving matrix, when D is the 1st dimension). You don't often see it being less than N even when interleaving is turned on, so this is a surprise.

The FEC setting for upstream is slightly stronger than downstream (12/156, or 8%), and the stats say that there were zero RSuncorr - so this setting is effective. However, they also say that OHFerr was 385 - which is odd when RSuncorr is zero!

I think your FEC counts are happening because the FEC process is turned on, rather than an indication of G.INP involvement. But *why* they are turned on is another matter...

[Ixel]

I don't know what PER means, but AgR I believe is the aggregate rate and OR is the overhead rate. Beyond that you'll need to look up what purpose they serve. AgR is presumably the total rate of all OR and such on top of the actual sync rate. I think one responsibility of the OR is to communicate certain things with the DSLAM, such as the error counters or when to do bitswapping and for what bits - for example.

[Mark07]

I believe this has been enabled on my line?..

Code: [Select]

Path 0
INP: 3.00 0.00
PER: 2.63 16.17
delay: 8.00 0.00
OR: 72.91 19.29
Interleave is also on, but that was triggered when OR were here disconnecting it a lot and never reset the DLM when they left  INP seems to have just appeared as 3