Error count percentage stuck due to cumulative counters

[idubs]

Hello,

I'm working on a driver for the Motorola B12 and have a question about how error counts are handled.

The B12's correctable/uncorrectable error counters are cumulative since last reboot and can't be reset via the API from my understanding.
My dashboard currently shows ~36% uncorrectable errors which is likely from an internet outage that occurred about a week ago.

The percentage makes the signal health look critical even though the modem is operating normally right now.

Two approaches I see:

1. Live with it and ignore the error rate unless an issue is happening
2. Add delta tracking to have the driver return the difference between polls

What would you guys recommend?

[itsDNNS]

Thanks for the detailed report. For the B12 driver, please keep the counters raw.

DOCSight drivers should return what the modem reports. If the modem exposes corrErrors / nonCorrErrors as cumulative counters since reboot, the driver should pass those cumulative values through.

Returning poll deltas in the driver would make the dashboard lose the real total, make event detection work on delta-of-delta data, and force every driver to keep its own state.

The stuck health state you are seeing is still a real DOCSight gap. #141 handles spikes that DOCSight observes while it is already running. Your case is different: DOCSight starts after the outage, so the first snapshot already contains old counters and there is no spike event to expire.

I split that into a tracked issue here: #468
#468

The fix should live in the core analysis layer: keep raw totals, baseline cumulative counters when DOCSight first sees them or after a reset, and score health from recent growth while still showing the modem's totals.

If you have two or three consecutive B12 polls where the counters stay flat, that would be useful test data for the baseline behavior.

[idubs]

Thanks for the reply and the context, makes sense it should be a core fix.

I can provide you the polls that happened overnight. Would backing up the instance and sending over the docsis_history.db be the easiest way to get those to you?

[itsDNNS]

Yes, please do not upload the full docsis_history.db here. It can contain more local history than we need for this.

For your own install, a modem reboot is a reasonable workaround. If the B12 counters are really "since modem boot", they should reset to 0 or near 0 after the restart.

That does not change #468, though. DOCSight should still recover without requiring a modem reboot just because the first snapshot already had old cumulative counters.

For test data, screenshots are enough. If you still have the pre-reboot state, a screenshot showing the error counts / health after they stayed flat overnight would help. After the reboot, the most useful thing is simply confirming whether the correctable and uncorrectable counters start over at 0 or near 0.

No need to send the full DB publicly.