Project

General

Profile

Bug #4450

rate_ctr counter seems to omit recent changes in timed stats

Added by neels 27 days ago. Updated 26 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
libosmocore
Target version:
-
Start date:
03/09/2020
Due date:
% Done:

0%

Spec Reference:

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?

History

#1 Updated by laforge 26 days 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

#2 Updated by laforge 26 days 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

#3 Updated by laforge 26 days 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)