Bug #4450
closedrate_ctr counter seems to omit recent changes in timed stats
0%
Description
After having just attached 200 MS in a short time, the vty 'show stats' yields:
Successful Location Update procedures.: 200 (0/s 0/m 0/h 0/d)
How can the 200 LU have been successful just now, but still be zero for all of 0/s 0/m 0/h 0/d?
Updated by laforge about 4 years ago
- Project changed from OsmoMSC to libosmocore
- Subject changed from osmo-msc stats: LU counter seems to omit recent changes in timed stats to rate_ctr counter seems to omit recent changes in timed stats
- Category set to libosmocore
Updated by laforge about 4 years ago
On Mon, Mar 09, 2020 at 10:05:21PM +0000, neels [REDMINE] wrote:
After having just attached 200 MS in a short time, the vty 'show stats' yields:
Successful Location Update procedures.: 200 (0/s 0/m 0/h 0/d)
How can the 200 LU have been successful just now, but still be zero for all of 0/s 0/m 0/h 0/d?
This is "normal" with the way rate_ctr have worked since their inception in 2010.
They are based around a 1s periodic timer, and each interval is updated only at the expiration of the interval, i.e. the second timer is updated every second, the minute timer every minute, the hour timer every hour, the day timer every day. See rate_ctr_group_intv()
and interval_expired()
in source:src/rate_ctr.c
Updated by laforge about 4 years ago
I'm not saying it cannot be done differently, I'm just saying it is as it has always been, and is not a surprise.