<div dir="ltr">On a Archlinux machine, Core i7 Haswell:<div><br></div><div><div>6> z:test().</div><div>[5001,5001,5001,5001,5001,5001,5001,5001,5001,5001]</div></div><div><br></div><div>This is what I expect to see. I'm awoken on the right flank up to one millisecond after.</div><div><br></div><div>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.</div><div><br></div><div>Enable dtrace and hunt :)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 21, 2016 at 10:40 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">mac os-x El Capitan 10.11.2<br>
Macbook retina pro<br>
3.1 GHz core i7<br>
16 GB ram<br>
<br>
Can you run the above program locally and post back the results?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
/Joe<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sun, Feb 21, 2016 at 10:34 PM, Felix Gallo <<a href="mailto:felixgallo@gmail.com">felixgallo@gmail.com</a>> wrote:<br>
> What os and hardware are you seeing these results on?<br>
><br>
> On Feb 21, 2016 1:20 PM, "Joe Armstrong" <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br>
>><br>
>> 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<br>
>> zero.<br>
>><br>
>> I tried erl -snp disable and setting process_flag(priority, max) but the<br>
>> 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<br>
>> 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<br>
>> >> sent<br>
>> >> and<br>
>> >> the time I want it to be sent - but I'd like it to be much more<br>
>> >> accurate<br>
>> >> (sub ms if possible)<br>
>> ><br>
>> ><br>
>> > I would start by making measurements without the network component. When<br>
>> > you<br>
>> > would send the gen_udp message, you take a timestamp, and analyze the<br>
>> > skew<br>
>> > from the suggested skew. This lets you estimate the overhead of the rest<br>
>> > 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<br>
>> > expect.<br>
>> > But note that if you sleep for, say, 40ms, you will be awoken on the<br>
>> > 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<br>
>> > suggesting<br>
>> > the VM has lots of work to do at that moment. And of course such stuff<br>
>> > 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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div>