summaryrefslogtreecommitdiffstats
path: root/src/rate_ctr.c
Commit message (Collapse)AuthorAgeFilesLines
* [doc] rate_ctr: Extend Doxygen API documentation with human-readable text on ↵Harald Welte2017-10-161-2/+35
| | | | | | its use Change-Id: If9abd46e1b0ebb6114522418fd3b45c1d802968a
* doxygen: unify use of \file across the boardNeels Hofmeyr2017-06-231-7/+3
| | | | | | | | | | | | | | | | | Considering the various styles and implications found in the sources, edit scores of files to follow the same API doc guidelines around the doxygen grouping and the \file tag. Many files now show a short description in the generated API doc that was so far only available as C comment. The guidelines and reasoning behind it is documented at https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation In some instances, remove file comments and add to the corresponding group instead, to be shared among several files (e.g. bitvec). Change-Id: Ifa70e77e90462b5eb2b0457c70fd25275910c72b
* doxygen: enable AUTOBRIEF, drop \briefNeels Hofmeyr2017-06-231-10/+10
| | | | | | | | | | Especially for short descriptions, it is annoying to have to type \brief for every single API doc. Drop all \brief and enable the AUTOBRIEF feature of doxygen, which always takes the first sentence of an API doc as the brief description. Change-Id: I11a8a821b065a128108641a2a63fb5a2b1916e87
* update/extend doxygen documentationHarald Welte2017-06-121-0/+1
| | | | | | | | | It's a pity that even with this patch we still are fare away from having the whole API documented. However, at least we have a more solid foundation. Updates not only extend the documentation, but also make sure it is rendered properly in the doxygen HTML. Change-Id: I1344bd1a6869fb00de7c1899a8db93bba9bafce3
* timer: add osmo_timer_setup()Pablo Neira Ayuso2017-05-091-1/+1
| | | | | | | | | | | | | | | Add a new function timer function to set up the timer, similar to what we have in the Linux kernel. This patch also converts existing opencoded timer setup in the libosmocore tree as initial client of this new function. This patch implicitly removes function callback passed by reference that defeat compile time type validation. Compile-tested only, but I ran make check that reports success when testing timer infrastructure. Change-Id: I2fa49972ecaab3748b25168b26d92034e9145666
* Update doxygen annotations in libosmocoreHarald Welte2016-05-051-3/+20
| | | | | This adds and improves doxygen API descriptions all over libosmocore, reducing the 'white spots' that don't have any documentation.
* stats: Add TODO comment to rate_ctrJacob Erlbeck2015-11-261-0/+3
| | | | | | | | | | Currently the counters are scanned twice, once for interval computation and once for reporting. This adds a reminder to move the interval computation code to a special stats reporter which just shall update the fields. Sponsored-by: On-Waves ehf
* core: Extend rate_ctr by helper functionsJacob Erlbeck2015-10-281-0/+41
| | | | | | | | | | | | | | | | | | | | | | | For global value reporting, some additional helper functions are needed. The statsd protocol expects differential counter values, which are currently not provided by rate_ctr (except for s/m/h/d intervals). This commit adds several helper functions to rate_ctr: - rate_ctr_difference returns the counter delta since the last call to this function for a given counter - rate_ctr_for_each_counter iterates through each counter of a group - rate_ctr_for_each_group iterates through all globally registered counter groups Note that the rate_ctr_difference function can only be used by a single backend, since it modifies the 'previous' field in the rate_ctr obj. Sponsored-by: On-Waves ehf
* doc: Fix the Doxygen section endingsSylvain Munaut2012-04-181-1/+1
| | | | Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
* doxygen: Add docs for rate_ctrHarald Welte2011-08-171-0/+19
|
* timer: use namespace prefix osmo_timer*Pablo Neira Ayuso2011-05-071-3/+3
| | | | | | | | | | | | | | Summary of changes: s/struct timer_list/struct osmo_timer_list/g s/bsc_add_timer/osmo_timer_add/g s/bsc_schedule_timer/osmo_timer_schedule/g s/bsc_del_timer/osmo_timer_del/g s/bsc_timer_pending/osmo_timer_pending/g s/bsc_nearest_timer/osmo_timers_nearest/g s/bsc_prepare_timers/osmo_timers_prepare/g s/bsc_update_timers/osmo_timers_update/g s/bsc_timer_check/osmo_timers_check/g
* stats: Fix the compiler warningsHolger Hans Peter Freyther2011-04-181-2/+2
| | | | Do not remove the const, include strings.h for strcmp
* Add functions to search for rate counters by nameDaniel Willmann2011-04-091-0/+34
| | | | * rate_ctr_get_group_by_name_idx, rate_ctr_get_by_name
* include: reorganize headers file to include/osmocom/[gsm|core]Pablo Neira Ayuso2011-03-231-5/+5
| | | | | | | | | | | | This patch moves all GSM-specific definitions to include/osmocom/gsm. Moreover, the headers in include/osmocore/ have been moved to include/osmocom/core. This has been proposed by Harald Welte and Sylvain Munaunt. Tested with `make distcheck'. Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
* rate_ctr: No need to include the inttypes.hHolger Hans Peter Freyther2010-12-201-1/+0
| | | | | | There should not be any u_int*_t types in this file, no need to include this file. It is breaking compilation with the last x86 build of GNU ARM for GCC 3.4.
* [rate_ctr] always 'overflow' in next larger inetrval when interval endsHarald Welte2010-05-131-0/+6
| | | | | | | | | | | If a second ends, we add the number of events in that just-ended second to the number of events in the currently running minute. The same happens at the end of a minute: We add the number of events in that just-ended minute into the number of events of the still-running hour, etc. This gives a much more meaningful numbers and we don't end up with "12 events per second, but 0 events per minute" kind of situations anymore.
* rate_counters: Remove group-name-sprintf-with-idx stringHarald Welte2010-05-131-3/+0
|
* rate_ctr: Store the numeric index as part of 'rate_ctr_group'Harald Welte2010-05-131-0/+1
|
* Add new 'rate counter' implementation to libosmocoreHarald Welte2010-05-131-0/+124
A 'rate counter' is a counter that counts events but also keeps track of the rate of events (per second, minute, hour and day). 'rate counters' are generally abstracted in 'rate counter groups', which are instances of a 'rate counter group description'. This way we can have e.g. a description describing what kind of counters a BTS (or TRX) has - and we can then create one instance of that group for every BTS or TRX that exists.