Thanks Dave!!!.

I could see precision was indeed the problem. I think it is because the
slots are missed due to below check in tw_timer_expire_timers_internal(...)
when now time is behind the calculated next_run_time.
*  /* Shouldn't happen */*
*  if (PREDICT_FALSE (now < tw->next_run_time))*
*    return callback_vector_arg;*
This leads to nticks loop -  *for (i = 0; i < nticks; i++) *run for more
than once in subsequent advance wheels ,internally calling registered
callbacks nticks times based on conditions.

I could not improve much on precision given the system constraints.I tried
another approach in which return vector list from
tw_timer_expire_timers_internal(...)
is used instead of callback mechanism.
I got result as expected i.e vec_len(expired_timer) as 1. I was expecting
it to behave similarly and return vec_len as nticks times because
internally it must be creating a vector, but that is not the case.

Do you see any difference in approach callback mechanism and return vectors
are implemented in tw_timer_expire_timers_XXX(...).

Thanks,
-Shaligram


On Sun, 9 Dec 2018 at 05:32, Dave Barach (dbarach) <dbar...@cisco.com>
wrote:

> Probably due to the vpp process sitting in an epoll_pwait(). See
> .../src/vlib/unix/input.c:linux_epoll_input_inline(...).
>
>
>
> The tw_timer code does its best, but if you don’t call the
> tw_timer_expire_timers_XXX(...) method precisely it won’t yield the sort of
> precision you’re looking for.
>
>
>
> If you configure the timer wheel at 100ms granularity you should expect
> timers to pop within +-50 ms of when you expect them to pop, even if you
> call the tw_timer_expire_timers_XXX method precisely. The code picks the
> nearest slot, and if slots are 100ms wide, well, you get the idea.
>
>
>
> Dave
>
>
>
> *From:* vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *
> shaligra...@gmail.com
> *Sent:* Saturday, December 8, 2018 1:54 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] Timer expiry spikes in TW timer implementation
>
>
>
> Hi,
>
> I am trying to implement single 10sec precision periodic timer using TW.
> Below is the config. using the reference from test_tw_timer.c (Really
> helpful).
>
> tw_timer_wheel_init_2t_1w_2048sl with 0.1 sec granularity.
> tw_timer_start_2t_1w_2048sl with 100 as ticks.
> I have used the process node approach
> with tw_timer_expire_timers_2t_1w_2048sl check at every 0.1 sec
> using vlib_process_suspend(...). In the callback, timer is again started.
>
> My expectation was I would be receiving  callback
> to expired_timer_single_callback() at every 10 sec.
> In actual, the callbacks are getting called at every 10sec apart. But
> sometimes there are some unwanted callback at irregular frequency for the
> same handle( i.e timer_id, pool_index). Note that this is the case either
> for main_core or workers. For erroneous scenarios, time diff from previous
> callback is inorder of ~ 0.1 ms(expected 10sec).
>
> Any pointers would of great help.
>
> Thanks,
> -Shaligram
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11591): https://lists.fd.io/g/vpp-dev/message/11591
Mute This Topic: https://lists.fd.io/mt/28677304/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to