<div dir="ltr"><br><div class="gmail_extra">On 26 May 2015 at 19:14, Felix Gallo <span dir="ltr"><<a href="mailto:felixgallo@gmail.com" target="_blank">felixgallo@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>For a game server, I have a large number (~3000) of concurrent gen_fsm processes which need to send out UDP packets every 30 milliseconds.  Each individual UDP-sending function can be presumed to be very short (<1ms) and not dominate or otherwise affect the scheduling.<br></div><div><br></div><div>I've tested a number of different scenarios:</div><div><br></div><div>1.  Each gen_fsm schedules itself via the gen_fsm timeout mechanism.  This is the easiest and most natural way, but jitter can be +7ms in the 95% case, and I occasionally see unusual events (e.g. timeout event happens when only 25-28ms of real time have elapsed, despite 30ms being scheduled).  </div></div></blockquote><div><br></div><div>Here are a few ideas, obviously all untested.<br><br></div><div>* How about setting the timer to fire initially at 10-15ms, and adjust the next timer interval based on observed drift?<br></div><div>* Let all the gen_fsm processes insert the packets they have to send into an ordered_set (ordered by time) ets table and have a single process which is checking the ETS table for messages to send at a certain point in time?<br></div><div>* Do you have any control on the receiving end? Can some smoothing of this jitter be done there?<br><br></div><div>Chandru<br></div></div></div></div>