<div dir="ltr">For #1 and #2, I'm using the 4-item tuple return value for state calls in gen_fsm:StateName/2:<div><br></div><div><span style="color:rgb(0,0,0);font-family:Courier,monospace;font-size:medium;font-weight:bold">{next_state,NextStateName,NewStateData,Timeout}</span><br><div><br></div><div>e.g.:</div><div><br></div><div>{ next_state, s_firststate, StateData#state{ last_time = NewTime, count = Count + 1, pid = NotificationPid, jitters = [Jitter | Jitters] }, TickInterval };</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 11:42 AM, Dmitry Kolesnikov <span dir="ltr"><<a href="mailto:dmkolesnikov@gmail.com" target="_blank">dmkolesnikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hello,<br>
<br>
I am curious about #1. Are you using timer or send_after?<br>
<span class="HOEnZb"><font color="#888888"><br>
- Dmitry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On 26 May 2015, at 21:14, Felix Gallo <<a href="mailto:felixgallo@gmail.com">felixgallo@gmail.com</a>> wrote:<br>
><br>
> 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>
><br>
> I've tested a number of different scenarios:<br>
><br>
> 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).<br>
><br>
> 2.  One gen_fsm 'god timer' process schedules itself and sends out messages to all of the concurrent gen_fsms to trigger them to send out their UDP packets upon its own timeout.  Jitter is more variable, probably because the BEAM decides that the god timer is being too chatty, and sometimes the gen_fsms overwhelm the god timer in the schedulers.<br>
><br>
> 3.  One port 'god timer' process (written in C, emitting a byte every 30ms).  Jitter is significantly reduced over #2 because apparently port processes get better scheduling and BEAM doesn't get as angry at the chattiness.  About on par with #1, maybe a little better, but the design is unpretty owing to the increased complexity.<br>
><br>
> Additionally, I've heard of someone using a c-written port-process god-timer per-fsm, which sounds to me like it would have the absolute best latency scenario but would involve several thousand external processes, all competing with erlang for thread execution, which sounds even unprettier.  Haven't tested that one.<br>
><br>
> Ideally I'd get as close to isochronous as possible, because the game 'feels' right if the stream of incoming packets is uniform.<br>
><br>
> None of the solutions gets me quite where I wanted; it's possible that any of the above are the optimal available path and I just don't know that yet, but I'm wondering if anyone has traveled down this same road and has advice, tuning secrets, or other plans to share.<br>
><br>
> F.<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</div></div></blockquote></div><br></div>