This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
neels gerrit-no-reply at lists.osmocom.orgneels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/25973 ) Change subject: add time_cc API: cumlative counter for time, reported as rate_ctr ...................................................................... Patch Set 1: this is pretty much exactly what this code is doing. (except you seem to be forgetting the detail that you also need to remember the time when cb_func last added to the counter.) There are two additions which i already mentioned: In addition, this code allows defining the precision: count seconds? count minutes? milliseconds? And in addition, this code allows defining the "rounding" behavior. 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. 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. These additions may be feature creep. I could invest more time to remove these features. Is it worth it? Then there is still the question of how to report the counter to statistics. 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. 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. -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/25973 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: Icdd36f27cb54b2e1b940c9e6404ba9dd3692a310 Gerrit-Change-Number: 25973 Gerrit-PatchSet: 1 Gerrit-Owner: neels <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge at osmocom.org> Gerrit-CC: pespin <pespin at sysmocom.de> Gerrit-Comment-Date: Tue, 02 Nov 2021 17:20:23 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20211102/9fe65ab2/attachment.htm>