[erlang-questions] lowering jitter: best practices?

[Felix Gallo]

Innovative thinking, Jesper!  But in this case, in this testbed, the fsms
aren't getting any messages other than those which they are delivering to
themselves.  Which adds to the intrigue.

I took your suggestion and tried using gen_fsm:start_timer/2.
Interestingly it slightly increased the jitter variance and the negative
jitter issue is still present.  It's possible that my, ah,
rapidly-and-pragmatically-built testbed suffers from some flaw, but I'm not
seeing it.

Here's my code:

https://gist.github.com/anonymous/47cde5e60a619319053f

Here's sample output on this small but moderately modern non-cloud osx
machine:

> test_fsm5:go(1000,40,40,10).
waiting for 1000 FSMs, tickrate 40
avg: 1324.1012703862662
max: 50219
min: -184
median: 1018
95th: 2615
99th: 9698

note that the max is 50ms of jitter; the min is negative 184 us jitter, and
the median jitter is about 1ms, which correlates well with my beliefs about
scheduler wakeup timers...

F.


On Tue, May 26, 2015 at 12:09 PM, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

>
> On Tue, May 26, 2015 at 8:52 PM, Felix Gallo <felixgallo@REDACTED> wrote:
>
>> {next_state,NextStateName,NewStateData,Timeout}
>
>
> This explains why you sometimes get less than 30ms sleep times. If an
> event reaches the process before Timeout, then the timeout is not
> triggered. Also, it may explain the jitter you are seeing, because an early
> event will reset the timeout. Try using gen_fsm:start_timer/2 or
> erlang:send_after...
>
> If the problem persists, check lcnt. If you are locked on the timer wheel,
> then consider release 18 :)
>
>
> --
> J.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150526/189a1c6c/attachment.htm>