[erlang-questions] Sending message at a specific and accurate time

[Jesper Louis Andersen]

On a Archlinux machine, Core i7 Haswell:

6> z:test().
[5001,5001,5001,5001,5001,5001,5001,5001,5001,5001]

This is what I expect to see. I'm awoken on the right flank up to one
millisecond after.

Immediate thought: this has to do with CPU frequency scaling and battery
saving features of OSX. Since nothing is done for 5 seconds, the system
throttles down and goes to sleep. When it is awoken again, you are enjoying
some latency.

Enable dtrace and hunt :)


On Sun, Feb 21, 2016 at 10:40 PM, Joe Armstrong <erlang@REDACTED> wrote:

> mac os-x El Capitan 10.11.2
> Macbook retina pro
> 3.1 GHz core i7
> 16 GB ram
>
> Can you run the above program locally and post back the results?
>
>
>
> /Joe
>
> On Sun, Feb 21, 2016 at 10:34 PM, Felix Gallo <felixgallo@REDACTED>
> wrote:
> > What os and hardware are you seeing these results on?
> >
> > On Feb 21, 2016 1:20 PM, "Joe Armstrong" <erlang@REDACTED> wrote:
> >>
> >> I tried a simpler program:
> >>
> >> test() -> test(10, []).
> >>
> >> test(0, L) ->
> >>     L;
> >> test(K, L) ->
> >>     T1 = ms_time(),
> >>     erlang:send_after(5000, self(), ping),
> >>     receive
> >>       ping ->
> >>          T2 = ms_time(),
> >>           test(K-1, [T2-T1|L])
> >>     end.
> >>
> >> ms_time() ->
> >>     erlang:system_time() div 1000000.
> >>
> >> Running this gives the following times
> >>
> >> [5001,5001,5006,5006,5002,5003,5006,5002,5002,5006]
> >>
> >> I'd expected 5000 or 5001
> >>
> >> This is in an unloaded OS with an unloaded erlang. 6ms seems very long -
> >> there are very few processes running and the system load is virtually
> >> zero.
> >>
> >> I tried erl -snp disable and setting process_flag(priority, max) but the
> >> results
> >> are pretty much the same.
> >>
> >> Waiting for shorter times like 100 ms makes no difference - still
> >> events with a 6 ms delay.
> >>
> >> I want to use this for scheduling music events (controlling synths) and
> >> these
> >> delays are far more than I expected.
> >>
> >> /Joe
> >>
> >>
> >>
> >> On Sun, Feb 21, 2016 at 8:32 PM, Jesper Louis Andersen
> >> <jesper.louis.andersen@REDACTED> wrote:
> >> >
> >> > On Sun, Feb 21, 2016 at 7:53 PM, Joe Armstrong <erlang@REDACTED>
> wrote:
> >> >>
> >> >> I'm getting about a 4 - 9 ms. inaccuracy in the time the messages is
> >> >> sent
> >> >> and
> >> >> the time I want it to be sent - but I'd like it to be much more
> >> >> accurate
> >> >> (sub ms if possible)
> >> >
> >> >
> >> > I would start by making measurements without the network component.
> When
> >> > you
> >> > would send the gen_udp message, you take a timestamp, and analyze the
> >> > skew
> >> > from the suggested skew. This lets you estimate the overhead of the
> rest
> >> > of
> >> > the system in isolation from your own code and the Erlang VM.
> >> >
> >> > Intuitively, 4 to 9 milliseconds is much higher than what I would
> >> > expect.
> >> > But note that if you sleep for, say, 40ms, you will be awoken on the
> >> > 41ms
> >> > flank at the earliest. This is because you are usually "inside" a
> >> > millisecond when you make the call so you start by taking the ceiling
> of
> >> > that milli-second before you.
> >> >
> >> > How much other work is your Erlang VM doing when you make these
> >> > measurements? You are saying between 4 to 9 ms, which is variance
> >> > suggesting
> >> > the VM has lots of work to do at that moment. And of course such stuff
> >> > will
> >> > affect the running time. You can switch priority of your processes up
> to
> >> > high, but this comes at the expense of other calculations if you can't
> >> > finish your work quickly in the process with high priority.
> >> >
> >> >
> >> > --
> >> > J.
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
>



-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160221/4e131d73/attachment.htm>