Print

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

[Oakserver]

Hi,

Recently moved from VDSL to g.fast and got myself a Zyxel XMG3927-B50A.

Everything seemingly running well, an improved number of ES errors - but I do seem to get a lot of FEC errors. I never used to see any FECs at all on my VDSL line so not sure if the technology is different in this respect?

I get a speedtest ping result of 6ms so it seems that the connection is pretty fast in terms latency and doesn't indicate any kind of interleaving (if such a thing still exists with g.fast)

I've posted my stats from my router:

============================================================================
    xDSL Training Status:   Showtime
                    Mode:   G.fast Annex A
            Traffic Type:   PTM Mode
             Link Uptime:   4 days: 5 hours: 37 minutes
============================================================================
       xDSL Port Details       Upstream         Downstream
               Line Rate:     30.243 Mbps      160.396 Mbps
    Actual Net Data Rate:     30.040 Mbps      159.959 Mbps
          Trellis Coding:         ON                ON
              SNR Margin:        6.5 dB            6.9 dB
            Actual Delay:          0 ms              0 ms
          Transmit Power:        4.0 dBm           0.0 dBm
           Receive Power:        4.7 dBm           3.0 dBm
              Actual INP:      535.0 symbols     552.0 symbols
Attainable Net Data Rate:     38.009 Mbps      192.199 Mbps
============================================================================

            xDSL Counters

           Downstream        Upstream
Since Link time = 37 min 37 sec
FEC:      100930697      4756
CRC:      12      0
ES:      8      1
SES:      0      1
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Retr:      0
HostInitRetr:   0
FastRetr:   0
FailedRetr:   0
FailedFastRetr:   0
Latest 15 minutes time = 9 min 27 sec
FEC:      350286      0
CRC:      0      0
ES:      0      0
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Retr:      0
HostInitRetr:   0
FastRetr:   0
FailedRetr:   0
FailedFastRetr:   0
Previous 15 minutes time = 15 min 0 sec
FEC:      480279      15
CRC:      1      0
ES:      1      0
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Retr:      N/A
HostInitRetr:   N/A
FastRetr:   N/A
FailedRetr:   N/A
FailedFastRetr:   N/A
Latest 1 day time = 5 hours 39 min 27 sec
FEC:      7039783      333
CRC:      1      0
ES:      1      0
SES:      0      0
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Retr:      0
HostInitRetr:   0
FastRetr:   0
FailedRetr:   0
FailedFastRetr:   0
Previous 1 day time = 24 hours 0 sec
FEC:      23109270      1118
CRC:      4      0
ES:      3      1
SES:      0      1
UAS:      0      0
LOS:      0      0
LOF:      0      0
LOM:      0      0
Retr:      0
HostInitRetr:   0
FastRetr:   0
FailedRetr:   0
FailedFastRetr:   0
Total time = 1 days 5 hours 39 min 27 sec
FEC:      100930697      4756
CRC:      12      0
ES:      8      1
SES:      0      1
UAS:      108      108
LOS:      0      0
LOF:      0      0
LOM:      0      0
Retr:      0
HostInitRetr:   0
FastRetr:   1
FailedRetr:   0
FailedFastRetr:   0
============================================================================

[burakkucat]

Despite the name, FECs are not errors. They are CRCs that "never happened" due to the successful operation of the error detection and correction code.

The change in technology, from the FDM (of VDSL2) to the TDM (of G.Fast), the higher frequencies used, etc, whilst still using the same metallic pathway as an RF transmission line, would undoubtedly be behind the change in the circuit's operating statistics.

As an example: Making use of the data you have posted, the first of the following two snippets would be clearly preferable --

Either:

Total time = 1 days 5 hours 39 min 27 sec
FEC:      100930697      4756
CRC:      12      0

Or:

Total time = 1 days 5 hours 39 min 27 sec
FEC:      12      0
CRC:      100930697      4756

[re0]

As b*cat said, they're just corrected errors.

Here is my previous 24 hours.

Code: [Select]

Previous 1 day time = 24 hours 0 sec
FEC:            185784          338
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
HostInitRetr:   0
FastRetr:       0
FailedRetr:     0
FailedFastRetr: 0
Granted, you are getting 124x more FECs than my own over an equivalent timeframe. But I would presume the connection is stable? I cannot comment on what is good since I haven't seen much in regards to other G.fast connection stats. But one thing is for sure, this is preferable over CRCs of a similar amount.

[j0hn]

My FEC count on FTTC jumps from circa 10,000/min up to circa 100,000/min if I connect Powerline adapters (homeplugs).
Hopefully you aren't using those.

If you never saw ANY fec's on FTTC then you might have been on an ECI cabinet on fastpath?
Don't think I've ever seen zero FEC's with G.INP active even on extremely clean/short lines.

As above though it's nothing to worry about.

[spaace]

My FEC count on FTTC jumps from circa 10,000/min up to circa 100,000/min if I connect Powerline adapters (homeplugs).
Hopefully you aren't using those.

If you never saw ANY fec's on FTTC then you might have been on an ECI cabinet on fastpath?
Don't think I've ever seen zero FEC's with G.INP active even on extremely clean/short lines.

As above though it's nothing to worry about.

i very rarely get FEC's or ES on a huawei cab with g.inp and fastpath (average around 1 ES a fortnight)

slightly off topic but is there any difference in latency from vdsl to gfast?

[re0]

slightly off topic but is there any difference in latency from vdsl to gfast?

Negligible. Perhaps if you had interleaving before [On ADSL/VDSL], then maybe. ISP routing is more likely to be a factor, I would imagine.

[j0hn]

i very rarely get FEC's or ES on a huawei cab with g.inp and fastpath (average around 1 ES a fortnight)

I see low numbers of fec all the time with g.inp.

I specifically said if they didn't see ANY fec it might be an ECI cabinet.
I've never seen zero fec with g.inp, even on shoe string length lines.

[Chrysalis]

Very high FEC combined with just a dozen CRC meaning error correction working a treat.

You don't have interleaving in the traditional sense, you will only have a latency hit when error correction occurs instead of "all the time".

[niemand]

The Zyxel is misreporting them which doesn't help. Check the times. Apparently more FECs in the past 37 minutes than the previous 5.5 hours, including that 37 minutes.

[spaace]

I see low numbers of fec all the time with g.inp.

I specifically said if they didn't see ANY fec it might be an ECI cabinet.
I've never seen zero fec with g.inp, even on shoe string length lines.

sorry for misunderstanding, i have not had any FECS since my last reboot/reconnect (15 days ago)