docsIfSigQMicroreflections - docsIfSigQCorrecteds - docsIfSigQUnerroreds

docsIfSigQMicroreflections is a measurement of how much of the signal is being reflected back to the sender when it hits things like an impedance mismatch. I have always used < ~20 dB as the rule of thumb but I don't remember exactly why.

docsIfSigQUnerroreds, docsIfSigQCorrecteds and docsIfSigQUncorrectables are all related.

When codewords ( How data is transmitted in Docsis) are received, one of three things happen:

1) it is received with no error, and the docsIfSigQUnerroreds counter is incremented
2) it is received with an error that FEC can account for, and the docsIfSigQCorrecteds is incremented
3) it is received with too many errors that FEC cannot account for, and the docsIfSigQUncorrectables counter is incremented

The counters by themselves are fairly unhelpful, in order to interpret this information you need to:

retrieve all three values, note the timestamp, retrieve all three values a second time, noting the timestamp.

now you need to get the difference between the second retrieval and the first retrieval, if the first retrieval is larger than the second, then the counter has overflowed and reset down to zero, and you need to account for it. This is done by taking 2^32 (for 32 bit counters) and subtracting first retrieval, and adding second retrieval to the result.

Now you need to determine the time difference between the two timestamps and divide the result from previous result by time in seconds to get the rate per second.

Now that you have a rate, you need to determine how much % wise each type is occurring.

Add docsIfSigQUnerroreds, docsIfSigQCorrecteds and docsIfSigQUncorrectables rates together, and take each individual value and divide it by the total which will give you the percentage of the data that falls into each category

Here is an example:

First Retrieval: timestamp 4/2/2023 9:50 AM
docsIfSigQUnerroreds : 4294967000
docsIfSigQCorrecteds : 5
docsIfSigQUncorrectables : 25

Second Retrieval: timestamp 4/2/2023 9:51 AM
docsIfSigQUnerroreds : 404
docsIfSigQCorrecteds : 50
docsIfSigQUncorrectables : 250

Difference in codewords:
docsIfSigQUnerroreds : (4,294,967,296 - 4294967000) + 404 = 700
docsIfSigQCorrecteds : 50 - 5 = 45
docsIfSigQUncorrectables : 250 - 25 = 225

Difference in timestamps in seconds
4/2/2023 9:51 AM - 4/2/2023 9:50 AM = 60 secs

Codewords Rate per second
docsIfSigQUnerroreds : 700 / 60 = 11.67
docsIfSigQCorrecteds : 45 / 60 = 0.75
docsIfSigQUncorrectables : 225 / 60 = 3.75

now to find the % of each type of codewords:
add all values together: 11.67 + 0.75 + 3.75 = 16.17 total codewords per second
docsIfSigQUnerroreds : 11.67/16.17 = 0.722 *100 = 72.2%
docsIfSigQCorrecteds : 0.75 / 16.17 = 0.046 * 100 = 4.6%
docsIfSigQUncorrectables : 3.75 / 16.17 = 0.232 * 100 = 23.2%

To me it makes the most sense to display this breakdown in a graph where, docsIfSigQUnerroreds are green, docsIfSigQCorrecteds are yellow, and docsIfSigQUncorrectables are red

So one that looked like this:
https://imgur.com/ygixNm5 would be considered great 100% unnerorred

whereas one that looks like this:
https://imgur.com/H0lczJ2 would be very bad, with 25% uncorrectable.

I have always used the rules:
<1% uncorrectable will be barely noticeable to a customer, but anything over 1% will cause problems and lead to a poor customer experience
<5% correctable will be barely noticeable to customers but is an indicator that uncorrectables are very likely (Docsis 3.0, for Docsis 3.1 correctables are not an indicator that uncorrectables are likely due to different FEC mechanics)

Other people prefer to break it down into a BER value, in this example, this would be 0.232 or 2.31e-1 anything larger than 0.000001 or 1e-6 will cause problems.