Print

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

[Bald_Eagle1]

My connection was unexpectedly put back on fastpath some 15 days ago.

We have occasionally seen low US FEC/RSCorr error counts when on fastpath, but I haven't previously seen DS FEC/RSCorr errors when on fastpath.

Compared to counts prior to being put back on fastpath, these DS errors are miniscule.
DS CRC errors are also unexpectedly now lower, but DS ES are expectedly higher.


Has anyone else seen this?

It may be a feature of the HG612's updated firmware as the last time my connection (briefly) ran on fastpath, DS FEC/RSCorr errors were completely zero.

[les-70]

  No not seen it.   Running the latest firmware in the Hg612 FEC were all zero on fast path.  Just been made interleaved and I am trying to puzzle out what levels of FEC/min are reasonable.  After looking at CRC/min on fast path the numbers seem huge.    Given previous values of CRC I am trying to understand why so many FEC occur, I notice that others seem to have these large values.

[konrado5]

RS-Coding is possible also on fast path. Check R parameter in "adsl info --stats".

Best regards
konrado5

[NewtronStar]

Running the latest firmware in the Hg612 FEC were all zero on fast path.  Just been made interleaved and I am trying to puzzle out what levels of FEC/min are reasonable

when on interleaved you don't want to see FEC's going above the 50K mark to often and if you hit 850K (burst errors) then its hello DLM thanks for increased Interleaving, so FEC's should be no more than 18K.

[NewtronStar]

Compared to counts prior to being put back on fastpath, these DS errors are miniscule.
DS CRC errors are also unexpectedly now lower, but DS ES are expectedly higher.

You will find once you get close to the max DS (Bearer) your line can handle you will find the DS ES will rise for me it's 30000Kbps if the Bearer is 28700Kbps I don't get any DS ES errors 

[Bald_Eagle1]

Cheers NS.



Yep, I've seen that on quite a number of connections that can't achieve 40 Mbps DS.

I'm currently in sync at slightly higher speeds than Attainable Rates, with DS SNRM peaking at 5.9dB at 2 pm.
At its lowest it is 5.4dB at 10 pm (which in my rational mind is nowhere enough fluctuation to bother about):-


From 2pm today:-

Max:   Upstream rate = 4483 Kbps, Downstream rate = 21744 Kbps
Bearer:   0, Upstream rate = 4516 Kbps, Downstream rate = 22271 Kbps



From 10 pm last night:-

Max:   Upstream rate = 4465 Kbps, Downstream rate = 20980 Kbps
Bearer:   0, Upstream rate = 4516 Kbps, Downstream rate = 22271 Kbps


R values are 14 DS & 12 US

Inp & delay values are zero for DS & US




My query was really about DS FEC/RSCorr errors though.

Your connection fairly often switches between fastpath & Interleaved doesn't it?

Do you ever see DS FEC/RSCorr errors when on fastpath?

[konrado5]

R values are 14 DS & 12 US

Inp & delay values are zero for DS & US

You have got RS without interleaving.

Best regards
konrado5

[Bald_Eagle1]

You have got RS without interleaving.

Are you able to explain why?

[konrado5]

R above 0 indicates "RS coding". FEC/RSCorr errors also indicates RS coding.

[Bald_Eagle1]

This also tells me:-

Code: [Select]

RS: 3459524930 3716447
RSCorr: 1314215 336
RSUnCorr: 214657 0



What I'd like to know is WHY have I got RS without interleaving?

Also, why have I now got it on DS when I have never seen it on DS before when on fastpatch?

[NewtronStar]

Max:   Upstream rate = 4465 Kbps, Downstream rate = 20980 Kbps
Bearer:   0, Upstream rate = 4516 Kbps, Downstream rate = 22271 Kbps

This has to one of those trick questions BE1

Your Max Attainable is higher than the Bearer on the DS would normally see this on the US never DS on my line, I can't see this as down to you being on Fastpath there seems to be something amiss 

the answers is your not on FastPath something in the stats is fooling you 

[Bald_Eagle1]

Max:   Upstream rate = 4465 Kbps, Downstream rate = 20980 Kbps
Bearer:   0, Upstream rate = 4516 Kbps, Downstream rate = 22271 Kbps

This has to one of those trick questions BE1

Your Max Attainable is higher than the Bearer on the DS would normally see this on the US never DS on my line, I can't see this as down to you being on Fastpath there seems to be something amiss 

But the Max Attainable isn't higher than the Bearer.

Bearer is almost 2 Mbps higher than Attainable in that example.


I've seen that quite a few times on various other users' connections.
I've also seen a low amount of US FEC errors on fastpath connections, but I've never previously seen DS FEC errors on a fastpath VDSL2 connection.



I can only assume that SNRM was higher when my connection resynced some 16 1/2 days ago.


EDIT:-

In fact, here are some of the stats from that resync:-

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 4516 Kbps, Downstream rate = 22160 Kbps
Bearer: 0, Upstream rate = 4516 Kbps, Downstream rate = 22271 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): 6.2 6.2
Attn(dB): 24.6 0.0
Pwr(dBm): 12.6 6.9


The connection had been up for 34 seconds by the time the resync data was obtained at 07:25:11, 26th April.





 

[Bald_Eagle1]

It may be pure coincidence, but I have just started remotely monitoring a connection that is a long way from the cabinet.


I only have a few hours worth of data, but I am seeing the same phenomenon i.e. DS FEC/RSCorr errors on a fastpath connection.


Both modems have the October firmware updates.


I wonder if this could be a feature of the updated firmware i.e. to introduce DS FEC/RSCorr on some fastpath connections that would otherwise see massive CRC errors & even more DS Errored Seconds, no doubt kicking DLM into aggressive action

Mine is connected to a Huawei DSLAM & the other is connected to an ECI DSLAM.

The snapshot & ongoing montages for the other connection are attached if anyone feels able to comment

[kitz]

Isnt this supposed to be what PhyR is all about.   
Error Correction on the fly and doesnt need interleaving to be applied?
I think it was discussed in another thread.

[Bald_Eagle1]

Thanks Kitz.


I'll have a look for that thread & generally read up on PhyR.


As we are not previously aware of this phenomenon on DS (i.e. via the original HG612 firmware version), it may well be one of the enhancements introduced with the October updated firmware.

As you are aware, the updated version also includes revised band plans, increased bitswapping & different (perhaps more realistic???) reporting of Signal Attenuation etc.

The updated version does definitely appear to have improved speeds slightly & increased stability for some longer connections (regardless of the make of DSLAM).