<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Nov 16, 2017 at 8:28 AM Atul Goyal <<a href="mailto:atulindore2@gmail.com">atulindore2@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>hi <br><br></div>I was wondering if there is a way to sleep for few u'sec in erlang . We are working on  Linux. And we have tried following solutions :<br></div><br></div></div></div></blockquote><div><br></div><div>If you require microsecond precision sleeps, then chances are you won't be happy with either Erlang (or for that matter, Go). The problem is that in a highly concurrent system, with soft-realtime constraints, you can't be guaranteed a wakeup within a window every time. If you have 100000 processes on the run-queue, you will have to wait, one way or the other.</div><div><br></div><div>Mind you, a hard realtime system wouldn't even allow you to start 100000 processes. It would start rejecting your spawns as soon as it can't make the guarantee.</div><div><br></div><div>What Erlang systems *do* tend to do well in this regard is that the performance degrades linearly as the system becomes overloaded. That is, it is considerably harder to monopolize the CPU resources in an Erlang system compared to other systems (Haskell and Go fares well here too, but they require more scheduling points at the moment to be injected by the programmer).</div><div><br></div><div>This is also the reason the precision is in milliseconds: it is far more likely that the Erlang system can meet the ms-window than the us or ns-windows. However, even that is no guarantee: a highly loaded system will fire timers late.</div><div><br></div><div>The best way to cope with the lack of precision is to have a low-level precise system which you periodically feed from the Erlang world. Much like how you wake up and feed the small soundcard buffer once in a while to keep on playing. This is also how you can handle a mobile phone cell system: handle the low-level latency stuff elsewhere and use the Erlang system for orchestration. </div></div></div>