work stealing / performance / latency

[Marco Leclerc]

Hi everyone, new CAF user here.

I have a question regarding latency in handling messages. Using the work stealing strategy, we see some latency added in our code execution, messages sometimes take a long time to reach our handlers. 

We're using event based actors and for example, we have 4 actors A to D, A receives the initial message, does some work, forward another message to B, etc and so on to actor D. 

If we keep the default settings, we usually see an added latency of 40ms. If I remove the sleep time of the moderate and relaxed strategies when configuring the system, no such latency but 100 %cpu.

template <class Worker>

  resumable* dequeue(Worker* self) { 

...

   if (strat.sleep_duration.count() > 0)

      std::this_thread::sleep_for(strat.sleep_duration);

...

I believe the sleep_for does not really sleep for the specified number of micro seconds thus adding unwanted delay.  

Oh yeah I'm running on windows :) I guess this explains...

Any ideas/suggestions on how to tweak these settings ? We do not mind spinning a little bit but for low workloads, using 100% cpu seems like overkill, is there a way to improve this on the windows platform?

I've used another actor library before (theron) where the workers would wait on a condition when the workload cools down. Is there a similar behavior I could achieve with the master branch code ?

Thanks for any hints or docs or examples I may not have found so far.

Marco

[Tullio Menga]

Hi Marco,

we had a similar issue (our use case is very sensible to latencies).

I confirm you that the this_thread::sleep_for() under Windows has  (unacceptably) high duration, preventing the scheduler policy to work properly.

 

We tried implementing a few solutions, with the following results:
A. a yeld() based implementation provides better reactiveness but still with relatively high CPU loads

B. another custom micro-sleep() based implementation, providing sleep times <40us, also provides good reactiveness but still with high CPU loads

C. an implementation using mutex on enqueing and wait_for() on scheduler provides the best compromise, but reducing the maximum throughput.

 

We are still investigating and benchmarking solution C in order to understand if is a viable alternative solution for better addressing low-latency requirements. We are also investigating some techniques from http://calvados.di.unipi.it/fastflow.

 

Tullio Menga

 

 

 

 

Da: actor-f...@googlegroups.com [mailto:actor-f...@googlegroups.com] Per conto di Marco Leclerc
Inviato: martedì 2 maggio 2017 14:20
A: actor-framework <actor-f...@googlegroups.com>
Oggetto: [caf] work stealing / performance / latency

--
You received this message because you are subscribed to the Google Groups "actor-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to actor-framewo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PRIVILEGED AND CONFIDENTIAL *******************************

This message contains confidential information and is intended only for the individual(s) addressed in the message. Please refer to DISCLAIMER for important disclaimers and the firm's regulatory position.