<div dir="ltr">Hi Henning, <br><br>Thanks for the effort, I was testing specifically in the dialog module, in the function get_expired_dlgs of dlg_timer.c <br><br>I will check with usrloc and get back to you but in the meantime i have changed the code to use epoch instead of ticks and it is accurate now.<br>
<br>I am running solaris 10 update 4, synched to ntp server<br><br>thanks again<br>Jason<br><br><br><br><div class="gmail_quote">On Thu, Sep 25, 2008 at 11:09 AM, Henning Westerholt <span dir="ltr"><<a href="mailto:henning.westerholt@1und1.de">henning.westerholt@1und1.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Wednesday 24 September 2008, Jason Penton wrote:<br>
> yes a 1s interval timer registered through the timer API. I then count the<br>
> ticks corresponding to 5 mins (current ticks + (5*60)). At the end the<br>
> stopwatch (wallclock) reads 5min and 20 secs. My question is what the<br>
> impact on for example the Dailog module which relies on these timers for<br>
> timeouts, etc. A timeout on a dialog of for example 3600 will be horribly<br>
> out.<br>
<br>
</div>Hi Jason,<br>
<br>
i tried to reproduce this inaccuracy with the usrloc timer on my machine this<br>
morning. I setup them to an 1 second interval, and let them run for 30<br>
minutes. I incremented a counter in the function, to keep track of the<br>
seconds, and also used an external stopwatch.<br>
<br>
I could not reproduce the problem you described:<br>
<br>
Sep 25 10:31:54 ca ../kamailio[16490]: ERROR:usrloc:timer: timer tick 0<br>
Sep 25 10:32:55 ca ../kamailio[16490]: ERROR:usrloc:timer: timer tick 60<br>
Sep 25 10:41:55 ca ../kamailio[16490]: ERROR:usrloc:timer: timer tick 600<br>
Sep 25 10:51:55 ca ../kamailio[16490]: ERROR:usrloc:timer: timer tick 1200<br>
Sep 25 10:59:56 ca ../kamailio[16490]: ERROR:usrloc:timer: timer tick 1680<br>
Sep 25 11:01:56 ca ../kamailio[16490]: ERROR:usrloc:timer: timer tick 1800<br>
<br>
This step of about 1 seconds is probably caused from the linux timer<br>
resolution, wich is 1ms on 2.6 kernels. This is also more or less visible on<br>
the stopwatch. I think this is a reasonable accuracy, given the usage of this<br>
timers.<br>
<br>
Do you use ntpc or chronyd to get a reliable time, and also sync the kernel<br>
clock on the test machine? Do you use a 2.6 kernel with the default HZ value?<br>
Perhaps you can also compare to the usrloc timer, here is the code i used:<br>
<br>
Index: modules/usrloc/ul_mod.c<br>
===================================================================<br>
--- modules/usrloc/ul_mod.c (revision 4991)<br>
+++ modules/usrloc/ul_mod.c (working copy)<br>
@@ -375,12 +375,13 @@<br>
destroy_ulcb_list();<br>
}<br>
<br>
-<br>
+static unsigned int timer_tick = 0;<br>
/*! \brief<br>
* Timer handler<br>
*/<br>
static void timer(unsigned int ticks, void* param)<br>
{<br>
+ LM_ERR("timer tick %d", timer_tick++);<br>
if (synchronize_all_udomains() != 0) {<br>
LM_ERR("synchronizing cache failed\n");<br>
<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Henning<br>
</font></blockquote></div><br></div>