Bridge Mode Channel Errors

[emveepee]

I have noticed that that I have two channels 31 and 32 on my XB8 gateway that seem to have excessive errors when I check the status.  The other channels are much lower some are under 1000.  Is there any suggestion on how to lower this.  There are no splits now.

BTW tech support is ridiculous on this.  I tried to explain this and they said wifi errors are normal and to choose another channel.  I tried to explain I wasn't even using wifi, but I eventually told me I didn't understand anything and he actually hung up on me continuing on about wif.

***Edited Labels***

[-G-]

The mods have not approved your image upload.

If you are seeing a massive number of Correctable Codewords errors on a downstream OFDM channel, don't worry about it; that is totally normal.

If you are seeing a massive number of Uncorrectable Codewords errors, on any channel, that is not good.

[emveepee]

Odd I see the image hopefully it will be there soon  It is Uncorrectable Codewords   Here is that row now, I do consider the difference massive.

2543 6211 3466882226 4013356473 57113 7179

[-G-]

@emveepee  The power levels and the signal-to-noise ratio on those problematic channels are WAY below acceptable norms.  Contact Rogers tech support and have them check your line conditions.  They will probably send a tech to investigate.

[emveepee · Accepted solution]

I finally had Rogers tech agree that there was a signal issue after a recent outage and they replaced the line to the house.  Now those problematic frequencies are good, last week the weren't even locking.  I guess with only 3 or 4 frequencies not working there is still plenty of bandwidth

They were able to detect this from the support desk so support really depends on who takes your call.

[fixplease]

Having a million Correctable errors every minute is NOT normal (lol).  That many FEC corrections per second is completely unacceptable and tanks your TCP throughput—it is not normal.  Even if you have zero Uncorrectable Errors might only mean the Modem FEC is barely keeping up.  The massive correctable counts still introduce enough latency/jitter to collapse TCP windows and can kill your streaming connections.  If you don't believe me, run WireShark on your Ethernet and then check your TCP Zero Window segments and Connection resets (RST).  Here is the chain of cause and effect with simple TCP resets:   

1. Huge FEC load → added latency/jitter

   • Even though FEC corrects every bad block, each correction takes time. When you’re doing thousands of corrections per second, the extra microseconds add up and inject jitter into every packet.

2. Latency/jitter → TCP stalls and timeouts

   • Your client expects fairly steady, low-latency responses. If a read or heartbeat RPC takes too long, the client will assume “the connection hung” and tear it down—sending a RST 

3. Client-initiated resets

   • the RST source on your system means the app is aborting its own socket when it hits its “unstable” timeout threshold. That’s exactly what you’d expect if the underlying TCP session feels like it’s stalled or misbehaving.

In short, massive correctable codeword counts don’t just vanish invisibly—they manifest as jitter and delayed frames that push the application into timeout-and-reset territory. So those resets that you will capture are almost certainly your client reacting to the physical-link noise load on those bad channel