On 06-03 15:44, Daniel-Constantin Mierla wrote: I see, we have the concept of slow and fast timers, so in that case the stuff that needs its own timer process should probably be executed from within the slow timer handler.

So what is the outcome of this discussion? Are we going to port the 'register_timer_process' from kamailio into the sip-router? This is a blocker for porting certain modules from kamailio to sip-router.

On Fri, Mar 6, 2009 at 10:31 AM, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote: > On Mar 06, 2009 at 14:53, Jan Janak <jan(a)iptel.org> wrote: >> On 06-03 15:44, Daniel-Constantin Mierla wrote: >> > Hello, >> > >> > On 03/06/2009 03:16 PM, Jan Janak wrote: >> >> Hello, >> >> >> >> There are two functions in the implementation of timers in kamailio, >> >> register_timer and register_timer_process. What is the different between those >> >> two functions and which should be used when? >> > the first one is to register a function to be executed by the main timer >> > process. Second is to create a new time process dedicated to run a >> > specific function. >> > >> >>  I noticed that, for example, the >> >> htable module seems to be using them interchangeably, there is a modparam >> >> which controls which function is gonna be used. >> >> >> >> Can we replace register_timer_process with register_timer function from the >> >> sip-router core? >> >> >> > Doesn't ser support to create a new timer process? How is it in the >> > timer module? Is the route executed by the main timer process? >> > >> > Idea behind dedicated timer process is to be able to execute timely >> > operations there without affecting the main timer which deals with >> > retransmissions, etc. >> >> I see, we have the concept of slow and fast timers, so in that case the stuff >> that needs its own timer process should probably be executed from within the >> slow timer handler. > > It depends, if it's very slow (e.g. can block for long periods of time > in the timer handle), it will be better to run in its own process. > > After a quick look at what register_timer_process(f, p, i, f) does, it seems > it's equivalent with: > > if (fork()==0) { sleep(interval); function(param); } > > (meaning one can have only 1 timer in one timer process, I haven't seen > a way to register more) > > If you only need 1 timer in your extra timer process, this can be done > in sr like above, but replacing fork() with fork_process(...). > If you need several timers and you want to be able to register/delete > them dynamically, you should use local_timer (local_timer is a > generalized very efficient timer, designed to be run "by hand" in a > single process). > > #include "local_timer.h" > > struct local_timer lt; > > if (fork_process(...,"my timer", ...)==0){ >    /* init */ >    init_local_timer(&lt, get_ticks_raw()); >    /* add timers */ >    local_timer_init(t1, handler1, param, 0); >    local_timer_add(&lt, t1, S_TO_TICKS(10) /* 10 s*/, get_ticks_raw()); >    /* as many times as needed */ >    while(..){ >        /* do something, e.g. poll some fds, read or even sleep(..) */ >        /* periodically call local_timer_run  which checks if any timer >           has expired and is so runs it */ >        local_timer_run(&lt, get_ticks_raw()); >        /* add more timers or delete some of them */ >        local_timer_del(&tl, t3); >       ... >    } > } > > > Andrei > > _______________________________________________ > Kamailio (OpenSER) - Devel mailing list > Devel(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel > http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel >

Should I understand that in ser there are two timer processes: - fast timer - slow timer If this is correct, I would like to have the ability to register an extra process for particular timer. On a multicore platform, several timers can be processed in parallel. Under heavy load, I experienced issues while using the standard timer process for the ratelimit module and therefore I registered the ratelimit timer with it's own process.

The timer interval for the ratelimit is configurable (called every second in my case). I'm using it to control inbound/outbound cps over several SIP trunks. Before having a separate timer for ratelimit, I wasn't able to properly control the cps due to timer jitter. If the slow timer doesn't introduce jitter, then I have no objections in using it. But if the slow timer is exposed to jitter due to other timers that can block and introduce jitter, then the slow timer is not a viable option here.

Helo Andrei, Can you point me to an example where fast timers are armed in sip-router, so I can try to update the ratelimit module.