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

[Rickard Green]

On 02/23/2016 05:06 PM, Felix Gallo wrote:
> 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
>

Running on a real time priority may perhaps improve things. Setting prio 
of the vm is something that typically should be done by the user since 
the vm doesn't know much about other processes on the system and how it 
should be prioritized against them. It would have been nice with a 
command line tool for setting things like this, but I didn't find any.

This can of course be implemented in the vm using the above api, but 
there need to be options for configuration of it by the user.

> 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
>

These kinds of primitives aren't optimal (from a functionality 
perspective), and can at least not be used out of the box.

Schedulers always need to be able to be woken by various events, but 
with the sleep time limited by a timeout. Such events might be; data has 
become available to read on a file descriptor. In this case you 
typically want to wait using select()/poll()/... Such events might also 
be an incoming message making a process runnable on a scheduler that 
currently is sleeping.

In order to use plain sleep primitives like those above, either:
- another thread needs to perform the sleep and then wake up the 
scheduler that should be woken, or
- another thread needs to wait for other events (such as fd events) and 
wake up the scheduler that should be woken using a signal.

This at least introduce scheduling of an extra thread which might make 
things worse.

Using them for a semi-busy wait (only checking for other events when 
woken by these primitives) will introduce increased latency for those 
events.

Regards,
Rickard

> 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
> <mailto: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 <mailto:rickard@REDACTED>>
>     Organization: Ericsson AB
>     To: Tony Rogvall <tony@REDACTED <mailto:tony@REDACTED>>
>
>     On 02/23/2016 02:29 PM, Tony Rogvall wrote:
>
>
>             On 22 feb 2016, at 15:55, Joe Armstrong <erlang@REDACTED
>             <mailto:erlang@REDACTED>> wrote:
>
>             On Mon, Feb 22, 2016 at 3:31 PM, Tony Rogvall
>             <tony@REDACTED <mailto: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 <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>