osmo_time_cc: rate_ctr presence should not affect counting
Make sure that osmo_time_cc counts exactly the same, regardless of a
rate_ctr being present or not. Only skip sending counter increments when
there is no rate counter, do not affect anything else.
In osmo-bsc, we are discussing a patch where an lchan redirects
osmo_time_cc counter increments to different rate counters depending on
its current type. In my comments I am also claiming that osmo_time_cc
works the same regardless of a rate_ctr being present or not. Looking at
the code, this is not actually the case.
Before this patch, when there is no rate_ctr, the reported_sum would
freeze, and as soon as a rate_ctr shows up, all counter increments from
the previous reported_sum would be sent to the newly set rate_ctr.
Instead, we want counter increments to simply be lost while there is no
rate_ctr set. IOW, rate_ctr == NULL should mean >/dev/null.
Related: I1b0670c47cb5e0b7776eda89d1e71545ba0e3347 (osmo-bsc)
Change-Id: I380b28d7ab0a6c8aab6c7e2a64bc73cab14863d2
diff --git a/src/time_cc.c b/src/time_cc.c
index ae99b58..05971fe 100644
--- a/src/time_cc.c
+++ b/src/time_cc.c
@@ -120,8 +120,6 @@
{
uint64_t delta;
uint64_t n;
- if (!tc->cfg.rate_ctr)
- return;
/* We report a sum "rounded up", ahead of time. If the granularity period has not yet elapsed after the last
* reporting, do not report again yet. */
if (tc->reported_sum > tc->sum)
@@ -139,7 +137,8 @@
/* integer sanity, since rate_ctr_add() takes an int argument. */
if (n > INT_MAX)
n = INT_MAX;
- rate_ctr_add(tc->cfg.rate_ctr, n);
+ if (tc->cfg.rate_ctr)
+ rate_ctr_add(tc->cfg.rate_ctr, n);
/* Store the increments of gran_usec that were counted. */
tc->reported_sum += n * GRAN_USEC(tc);
}
@@ -205,7 +204,7 @@
next_event = OSMO_MIN(next_event, next_forget_time);
}
/* Next rate_ctr increment? */
- if (tc->flag_state && tc->cfg.rate_ctr) {
+ if (tc->flag_state) {
uint64_t next_inc = now + (tc->reported_sum - tc->sum) + ROUND_THRESHOLD_USEC(tc);
next_event = OSMO_MIN(next_event, next_inc);
}