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

[Felix Gallo]

I threw every available command line option at this to see if improvement
could be seen --
erl +K true +sbwt very_long +sfwi 1 +swct very_eager +swt very_low
Erlang/OTP 18 [erts-7.2.1] [source] [64-bit] [smp:4:4] [async-threads:10]
[hipe] [kernel-poll:true]
Eshell V7.2.1  (abort with ^G)
1> t:test().
[1005971,1005730,1003351,1005205,1004924,1003375,1005130,
 1006166,1005846,1003769]

...perhaps a little, but nothing significant, unfortunately.

OSX turns out to have a rich tapestry of low latency timers:

https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html#//apple_ref/doc/uid/TP30000905-CH211-BABHGEFA

as do FreeBSD and Linux, although their model and guarantee are a little
less real-time:

https://www.freebsd.org/cgi/man.cgi?query=usleep&sektion=3&apropos=0&manpath=freebsd
http://man7.org/linux/man-pages/man2/nanosleep.2.html

even Windows can be, as usual, hackily coerced:

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

although usleep/nanosleep would probably be strictly better and not
noticeably more intensive than select() on the unices, using Mach's
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.

ideally, you could do something like:

[...]
process_flag(low_latency),
[...]

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.

Although perhaps the erlang way is to create quick_schedulers dual to
dirty_schedulers.

F.

On Tue, Feb 23, 2016 at 6:58 AM, Rickard Green <rickard@REDACTED> wrote:

> Missed reply all...
>
> -------- Forwarded Message --------
> Subject: Re: [erlang-questions] Sending message at a specific and accurate
> time
> Date: Tue, 23 Feb 2016 15:55:19 +0100
> From: Rickard Green <rickard@REDACTED>
> Organization: Ericsson AB
> To: Tony Rogvall <tony@REDACTED>
>
> On 02/23/2016 02:29 PM, Tony Rogvall wrote:
>
>>
>> On 22 feb 2016, at 15:55, Joe Armstrong <erlang@REDACTED> wrote:
>>>
>>> On Mon, Feb 22, 2016 at 3:31 PM, Tony Rogvall <tony@REDACTED> wrote:
>>>
>>>> L = fun Loop() -> receive after 1 ->  Loop()  end end.
>>>>> spawn_link(L).
>>>>>
>>>>
>>> Busy sleep :-) < I thought busy waiting was frowned upon>
>>>
>>> Actually after 10 works as well.
>>>
>>>
>> When running a busy sleep loop of 1 ms I get a 990 us diff from the
>> actual time
>> and when running a busy loop of 10 ms I get 1550 us diff.
>> BTW The same is true for smp disable
>>
>> Question for Richard really is why ? :-)
>>
>
> The accuracy of the timeout delivered by the underlying primitive used
> (select() on macosx). It seems that the accuracy is better for short
> timeouts than long timeouts using select() on macosx.
>
> Using the above approach you also need a bit of luck in the smp case.
> The looping process needs to execute on the same scheduler thread as the
> scheduler thread managing the timer you want to improve.
>
> Regards,
> Rickard
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160223/10d3268e/attachment.htm>