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] -=-=-=-=-=-=-=-=-=-=-=-
