<div dir="ltr">I've made a simple example.<br><br>The code is at <a href="https://gist.github.com/stolen/40eebd6225faf821153f1eeb5374f068">https://gist.github.com/stolen/40eebd6225faf821153f1eeb5374f068</a><div><br></div><div>I added the <a href="http://239.0.0.0/8">239.0.0.0/8</a> route as direct loopback (lo0 in OSX) to avoid network driver overhead.</div><div><br></div><div>40 dummy readers are enough to eat almost all 4 cores on my macbook (quite old i7 2 GHz):</div><div><br></div><div><div><font face="monospace, monospace"><div>Erlang/OTP 21 [RELEASE CANDIDATE 1] [erts-9.3.1] [source-dfc935298b] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]</div><div><br></div>1> c(udptest).</font></div><div><font face="monospace, monospace">{ok,udptest}</font></div><div><font face="monospace, monospace">2> udptest:start_sender({239,9,9,9}, 3999).</font></div><div><font face="monospace, monospace"><0.82.0></font></div><div><font face="monospace, monospace">3> [udptest:start_reader({239,9,9,9}, 3999) || _ <- lists:seq(1, 40)].</font></div><div><font face="monospace, monospace">[<0.84.0>,<0.85.0>,<0.86.0>,<0.87.0>,<0.88.0>,<0.89.0>,</font></div><div><font face="monospace, monospace"> <0.90.0>,<0.91.0>,<0.92.0>,<0.93.0>,<0.94.0>,<0.95.0>,</font></div><div><font face="monospace, monospace"> <0.96.0>,<0.97.0>,<0.98.0>,<0.99.0>,<0.100.0>,<0.101.0>,</font></div><div><font face="monospace, monospace"> <0.102.0>,<0.103.0>,<0.104.0>,<0.105.0>,<0.106.0>,<0.107.0>,</font></div><div><font face="monospace, monospace"> <0.108.0>,<0.109.0>,<0.110.0>,<0.111.0>,<0.112.0>|...]</font></div></div><div><font face="monospace, monospace">4> msacc:start(10000), msacc:print().<br>...</font></div><div><font face="monospace, monospace"> Thread alloc aux bifbusy_wait check_io emulator ets gc gc_full nif other port send sleep timers</font></div><div><font face="monospace, monospace">...</font></div><div><font face="monospace, monospace"> scheduler 59.95% 0.62% 0.14% 10.65% 0.00% 1.40% 0.00% 0.39% 0.00% 0.00% 1.74% 17.43% 0.00% 7.62% 0.06%<br><br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I'll build the fresh OTP on Linux box and check perf again.</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 24, 2018 at 1:58 PM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Wed, May 23, 2018 at 5:29 PM Danil Zagoskin <<a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a>> wrote:<br></span><div><span class=""><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">Hi!<br><br>We have a performance problem receiving lots of UDP traffic.<div>There are a lot (about 70) of UDP receive processes, each handling about 1 to 10 megabits of multicast traffic, with {active, N}.<br><br></div></div></blockquote><br><br></div></span><div class="gmail_quote">Suppose you read the packets, and then throw everything away, as a test. Are you then fast enough, or do you have a problem still? Chances are that the problem isn't the reception by itself.<br><br></div><div class="gmail_quote">memmove just means you are moving memory around a lot, but the question is: why?<br></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div></div>
</div>