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? 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?
thanks, Jan.
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.
Cheers, Daniel
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.
Jan.
On Mar 06, 2009 at 14:53, Jan Janak jan@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(<, get_ticks_raw()); /* add timers */ local_timer_init(t1, handler1, param, 0); local_timer_add(<, 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(<, get_ticks_raw()); /* add more timers or delete some of them */ local_timer_del(&tl, t3); ... } }
Andrei
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.
Regards, Ovidiu Sas
On Fri, Mar 6, 2009 at 10:31 AM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Mar 06, 2009 at 14:53, Jan Janak jan@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(<, get_ticks_raw()); /* add timers */ local_timer_init(t1, handler1, param, 0); local_timer_add(<, 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(<, get_ticks_raw()); /* add more timers or delete some of them */ local_timer_del(&tl, t3); ... } }
Andrei
Kamailio (OpenSER) - Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
On 09-03 21:19, Ovidiu Sas wrote:
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.
As far as I can tell, the timer process in kamailio serves the same purpose as the slow timer process in ser, I would thus recommend to convert everything that uses register_timer_process in kamailio to use the slow timer process in ser.
Of course I haven't investigated all the code in k. in detail, but it seems to me that the two mechanisms server the same purpose, given that k. doesn't have the slow timer process and we don't have separate timer processes in ser.
Jan.
On Fri, Mar 6, 2009 at 10:31 AM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Mar 06, 2009 at 14:53, Jan Janak jan@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(<, get_ticks_raw()); /* add timers */ local_timer_init(t1, handler1, param, 0); local_timer_add(<, 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(<, get_ticks_raw()); /* add more timers or delete some of them */ local_timer_del(&tl, t3); ... } }
Andrei
Kamailio (OpenSER) - Devel mailing list Devel@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.
Regards, Ovidiu Sas
On Mon, Mar 9, 2009 at 9:27 PM, Jan Janak jan@iptel.org wrote:
On 09-03 21:19, Ovidiu Sas wrote:
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.
As far as I can tell, the timer process in kamailio serves the same purpose as the slow timer process in ser, I would thus recommend to convert everything that uses register_timer_process in kamailio to use the slow timer process in ser.
Of course I haven't investigated all the code in k. in detail, but it seems to me that the two mechanisms server the same purpose, given that k. doesn't have the slow timer process and we don't have separate timer processes in ser.
Jan.
On Fri, Mar 6, 2009 at 10:31 AM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Mar 06, 2009 at 14:53, Jan Janak jan@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(<, get_ticks_raw()); /* add timers */ local_timer_init(t1, handler1, param, 0); local_timer_add(<, 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(<, get_ticks_raw()); /* add more timers or delete some of them */ local_timer_del(&tl, t3); ... } }
Andrei
Kamailio (OpenSER) - Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
On Mar 09, 2009 at 22:14, Ovidiu Sas osas@voipembedded.com wrote:
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.
Could you describe what is the ratelimit timer doing and how often is it called? (there are huge differences between the timer in k and sr, the timer in k is very inefficient and that's what you might have seen).
Anyway so far I've seen register_timer_process used only in 5 modules and I suspect in the worst case it can be replaced by fork_process(); while() { sleep(1); call_timer())} (which is basically what register_timer_process does). For this I wouldn't create a special function. If the needs arrives for more complex timers (ones that handle several different timeouts or need dynamically adding and removing), I will add something similar (based on local_timer.h), but that would return a timer_proc_handle so that more timers can be added to it at runtime (even from different processes if proper locking is used).
Andrei
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.
Regards, Ovidiu Sas
On Tue, Mar 10, 2009 at 3:29 AM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Mar 09, 2009 at 22:14, Ovidiu Sas osas@voipembedded.com wrote:
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.
Could you describe what is the ratelimit timer doing and how often is it called? (there are huge differences between the timer in k and sr, the timer in k is very inefficient and that's what you might have seen).
Anyway so far I've seen register_timer_process used only in 5 modules and I suspect in the worst case it can be replaced by fork_process(); while() { sleep(1); call_timer())} (which is basically what register_timer_process does). For this I wouldn't create a special function. If the needs arrives for more complex timers (ones that handle several different timeouts or need dynamically adding and removing), I will add something similar (based on local_timer.h), but that would return a timer_proc_handle so that more timers can be added to it at runtime (even from different processes if proper locking is used).
Andrei
On Mar 10, 2009 at 09:10, Ovidiu Sas osas@voipembedded.com wrote:
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.
I had a look at it and it qualifies for fast timer (it does very little work in the handler). Regarding jitter: why don't you compute the real timer_interval? This way even if the handler would be called a little later you would still get the real load. In sr you could always use get_ticks_raw() which is very fast and also recovers after suspend/hibernate (so you'll always have the correct ticks). This would help even if you use a separate process.
Andrei
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.
Regards, Ovidiu Sas
On Tue, Mar 10, 2009 at 9:45 AM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Mar 10, 2009 at 09:10, Ovidiu Sas osas@voipembedded.com wrote:
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.
I had a look at it and it qualifies for fast timer (it does very little work in the handler). Regarding jitter: why don't you compute the real timer_interval? This way even if the handler would be called a little later you would still get the real load. In sr you could always use get_ticks_raw() which is very fast and also recovers after suspend/hibernate (so you'll always have the correct ticks). This would help even if you use a separate process.
Andrei
On Mar 10, 2009 at 11:13, Ovidiu Sas osas@voipembedded.com wrote:
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.
#include "../../timer.h" #include "../../timer_ticks.h"
/* simple periodic timer handler */ static ticks_t timer_h(ticks_t ticks, struct timer_ln* tl, void* data) { DBG("timer habdler called at %d ticks, foo is %d \n", ticks, *(int*)data); return (ticks_t)(-1); /* periodical */ }
struct timer_ln *t; int foo;
t=timer_alloc(); if (t==0) goto error; timer_init(t, timer_handle, &foo, F_TIMER_FAST); foo=0; timer_add(t, MS_TO_TICKS(1500)); /* start it after 1500ms */ ...
In the code you can find an example in modules/tm/timer.[ch] (but is more complicated to follow since timer init and adding happen in separate functions). The timers are documented in doc/timers.txt (the above example is pasted from there, the only difference being F_TIMER_FAST instead of 0 in timer_init).
I've also added a fork_dummy_timer(...) function to sr, that is mostly equivalent to what register_timer_process() does. The main difference (besides params) is that this function immediately forks the timer process (as opposed to registering it), so you must call it from the modules child_init functions when the rank==PROC_MAIN (more details about when a process should be forked are in doc/modules_init.txt). Note though that I haven't tested it.
I also don't have anything against if somebody implements a compatible register_timer_process() (should be quite easy, one would only need to keep a list and then call fork_dummy_timer() on each element), as long as it would have a different name (since this would be not a "normal" timer). I don't think it's needed, but if somebody really wants it...
Andrei [...]
On Tuesday 10 March 2009, Andrei Pelinescu-Onciul wrote:
On Mar 09, 2009 at 22:14, Ovidiu Sas osas@voipembedded.com wrote:
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.
Could you describe what is the ratelimit timer doing and how often is it called? (there are huge differences between the timer in k and sr, the timer in k is very inefficient and that's what you might have seen).
Hi Andrei,
we used also the extra process timers, because the old k timers were not really performant under high load conditions. But if you say the ones from SER behave better in this regards they should be sufficient for our task, as we only needed them for some internal modules.
Cheers,
Henning
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Jan Janak -
Ovidiu Sas