[erlang-questions] erlang-questions Digest, Vol 200, Issue 4

[Christopher Phillips]

  Heh, I see I forgot to change the title when replying. Whoops.


  Sort of. I'd flow it like this -

  if
    fixed interval -> apply_interval();
    varied interval andalso not multiple timers firing nearly at the same
time -> timer:sleep(), spawn(fun() -> process() end), timer:sleep(); %One
timer at a time
    _Otherwise -> send_after() %Scales better when multiple timers are in
use, may still drift
  end

Basically, assume that one timer is extremely exact, but that two timers
set to wake up at the same time will cause them to drift. Assume also that
the amount of drift tapers off with the amount of distance in between the
two timers' wake time (interrupts and lock contention? I don't know the
reason). Optimize and architect accordingly; in testing with a few thousand
send_after calls, set to go off in 100 group batches, the drift I saw was
still < 40ms (probably far less, but it was related to video, so my
tolerance was 'frame accurate'). Again, this is based on my own
experiences, my hardware, YMMV, etc.


On Tue, Jan 13, 2015 at 3:01 PM, Imants Cekusins <imantc@REDACTED> wrote:

> .."trying to create many processes, with timers all having very close
> together stop times leads to very noticeable drift. The closer they are
> together, the worse it is."
>
> Would this be a fair summary:
>
> - timer works for pausing for at least a while;
>
> - when exact interval is critical, another solution may be necessary;
>
> - there are technical limits to timer, much like to the vm.
>
> The fact that both timer and vm can take a lot of wear does not mean that
> things should be piled up until vm breaks. Spreading the load may help.
>
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150113/940a1f6b/attachment.htm>