<div dir="ltr">I threw every available command line option at this to see if improvement could be seen -- <div><div>erl +K true +sbwt very_long +sfwi 1 +swct very_eager +swt very_low</div><div>Erlang/OTP 18 [erts-7.2.1] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:true]</div><div>Eshell V7.2.1 (abort with ^G)</div><div>1> t:test().</div><div>[1005971,1005730,1003351,1005205,1004924,1003375,1005130,</div><div> 1006166,1005846,1003769]</div></div><div><br></div><div>...perhaps a little, but nothing significant, unfortunately.</div><div><br></div><div>OSX turns out to have a rich tapestry of low latency timers:</div><div><br></div><div><a href="https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html#//apple_ref/doc/uid/TP30000905-CH211-BABHGEFA">https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html#//apple_ref/doc/uid/TP30000905-CH211-BABHGEFA</a><br></div><div><br></div><div>as do FreeBSD and Linux, although their model and guarantee are a little less real-time:</div><div><br></div><div><a href="https://www.freebsd.org/cgi/man.cgi?query=usleep&sektion=3&apropos=0&manpath=freebsd">https://www.freebsd.org/cgi/man.cgi?query=usleep&sektion=3&apropos=0&manpath=freebsd</a></div><div><a href="http://man7.org/linux/man-pages/man2/nanosleep.2.html">http://man7.org/linux/man-pages/man2/nanosleep.2.html</a><br></div><div><br></div><div>even Windows can be, as usual, hackily coerced: </div><div><br></div><div><a href="http://www.codeguru.com/cpp/w-p/system/timers/article.php/c5759/Creating-a-HighPrecision-HighResolution-and-Highly-Reliable-Timer-Utilising-Minimal-CPU-Resources.htm">http://www.codeguru.com/cpp/w-p/system/timers/article.php/c5759/Creating-a-HighPrecision-HighResolution-and-Highly-Reliable-Timer-Utilising-Minimal-CPU-Resources.htm</a><br></div><div><br></div><div>al<font face="arial, helvetica, sans-serif">though usleep/nanosleep would probably be strictly better and not noticeably more intensive than select() on the unices, using Mach's <font color="#000000">THREAD_TIME_CONSTRAINT_POLICY or the windows hack would put all sleeping schedulers in a busy loop, so that would be something you might want fine grained control over.</font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000"><br></font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000">ideally, you could do something like:</font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000"><br></font></font></div><div><font color="#000000" face="arial, helvetica, sans-serif">[...]</font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000">process_flag(low_latency),</font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000">[...]</font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000"><br></font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000">to signal to the schedulers that you want at least one thread to be running with significantly improved timing granularity, and while at least one low latency process existed, one or more schedulers would run under the specific regime and bind all the low latency processes to it.</font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000"><br></font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000">Although perhaps the erlang way is to create quick_schedulers dual to dirty_schedulers.</font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000"><br></font></font></div><div><font face="arial, helvetica, sans-serif"><font color="#000000">F.</font></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 23, 2016 at 6:58 AM, Rickard Green <span dir="ltr"><<a href="mailto:rickard@erlang.org" target="_blank">rickard@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Missed reply all...<span class=""><br>
<br>
-------- Forwarded Message --------<br>
Subject: Re: [erlang-questions] Sending message at a specific and accurate time<br></span>
Date: Tue, 23 Feb 2016 15:55:19 +0100<br>
From: Rickard Green <<a href="mailto:rickard@erlang.org" target="_blank">rickard@erlang.org</a>><br>
Organization: Ericsson AB<br>
To: Tony Rogvall <<a href="mailto:tony@rogvall.se" target="_blank">tony@rogvall.se</a>><span class=""><br>
<br>
On 02/23/2016 02:29 PM, Tony Rogvall wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 22 feb 2016, at 15:55, Joe Armstrong <<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>> wrote:<br>
<br>
On Mon, Feb 22, 2016 at 3:31 PM, Tony Rogvall <<a href="mailto:tony@rogvall.se" target="_blank">tony@rogvall.se</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
L = fun Loop() -> receive after 1 -> Loop() end end.<br>
spawn_link(L).<br>
</blockquote></blockquote>
<br>
Busy sleep :-) < I thought busy waiting was frowned upon><br>
<br>
Actually after 10 works as well.<br>
<br>
</blockquote>
<br>
When running a busy sleep loop of 1 ms I get a 990 us diff from the actual time<br>
and when running a busy loop of 10 ms I get 1550 us diff.<br>
BTW The same is true for smp disable<br>
<br>
Question for Richard really is why ? :-)<br>
</blockquote>
<br></span>
The accuracy of the timeout delivered by the underlying primitive used<br>
(select() on macosx). It seems that the accuracy is better for short<br>
timeouts than long timeouts using select() on macosx.<br>
<br>
Using the above approach you also need a bit of luck in the smp case.<br>
The looping process needs to execute on the same scheduler thread as the<br>
scheduler thread managing the timer you want to improve.<br>
<br>
Regards,<br>
Rickard<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></div>