libosmocore - [no description]

	Commit message (Collapse)	Author	Age	Files	Lines
*	Update doxygen annotations in libosmocore	Harald Welte	2016-05-05	1	-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_ctr	Jacob Erlbeck	2015-11-26	1	-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 functions	Jacob Erlbeck	2015-10-28	1	-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 endings	Sylvain Munaut	2012-04-18	1	-1/+1
\| \| \| \|	Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
*	doxygen: Add docs for rate_ctr	Harald Welte	2011-08-17	1	-0/+19
\|
*	timer: use namespace prefix osmo_timer*	Pablo Neira Ayuso	2011-05-07	1	-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 warnings	Holger Hans Peter Freyther	2011-04-18	1	-2/+2
\| \| \| \|	Do not remove the const, include strings.h for strcmp
*	Add functions to search for rate counters by name	Daniel Willmann	2011-04-09	1	-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 Ayuso	2011-03-23	1	-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.h	Holger Hans Peter Freyther	2010-12-20	1	-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 ends	Harald Welte	2010-05-13	1	-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 string	Harald Welte	2010-05-13	1	-3/+0
\|
*	rate_ctr: Store the numeric index as part of 'rate_ctr_group'	Harald Welte	2010-05-13	1	-0/+1
\|
*	Add new 'rate counter' implementation to libosmocore	Harald Welte	2010-05-13	1	-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.