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