<p style="white-space: pre-wrap; word-wrap: break-word;">this is pretty much exactly what this code is doing.<br>(except you seem to be forgetting the detail that you also need to remember the time when cb_func last added to the counter.)</p><p style="white-space: pre-wrap; word-wrap: break-word;">There are two additions which i already mentioned:</p><p style="white-space: pre-wrap; word-wrap: break-word;">In addition, this code allows defining the precision: count seconds? count minutes? milliseconds?</p><p style="white-space: pre-wrap; word-wrap: break-word;">And in addition, this code allows defining the "rounding" behavior.<br>Should we report the first increment already at the first millisecond, or at half a second, or stay with reporting 0 until 0.9999s of true flag.<br>It makes a big difference in resulting statistics: if all channels are allocated for short fractions of a second, you may never notice that channels were ever exhausted. Because I can't fathom the users' preferences here, I made things configurable by T timers.</p><p style="white-space: pre-wrap; word-wrap: break-word;">These additions may be feature creep.<br>I could invest more time to remove these features.<br>Is it worth it?</p><p style="white-space: pre-wrap; word-wrap: break-word;"><br>Then there is still the question of how to report the counter to statistics.<br>I still find a rate counter more useful than a stat item. From the point of view of a user's evaluation of statistics, there seems to be not much of a difference between stat item and rate counter. But on the VTY I can trivially see the percentage of exhausted channels because we display counters per second, per minute, per hour. If I see 1/sec, 30/min, 35/hour, then I immediately know that currently all channels are exhausted, this was so for half the time in the last minute, but this situation apparently just started recently because there were only few seconds of the last hour of exhaustion.</p><p style="white-space: pre-wrap; word-wrap: break-word;">If you argue for a stat item instead then let's hear the argument for it. I'm not convinced that a simple incrementing value in a stat item has any benefits over a rate counter. If I see a value of 12345 it only tells me that since whenever osmo-bsc started, there were 12k seconds of channel exhaustion. It says nothing about now or recent events, and requires elaborate evaluation (e.g. elastic search statistics engine) to make any use of; IOW you need to watch it change over time.</p><p><a href="https://gerrit.osmocom.org/c/osmo-bsc/+/25973">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-bsc/+/25973">change 25973</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-bsc/+/25973"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-bsc </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: Icdd36f27cb54b2e1b940c9e6404ba9dd3692a310 </div>
<div style="display:none"> Gerrit-Change-Number: 25973 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-CC: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-CC: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Tue, 02 Nov 2021 17:20:23 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>