[erlang-questions] UDP receive performance

[pablo platt]

 Does this bug only affect multicast UDP or also normal UDP?

What values should I use for buffer and recbuf in a UDP socket receiving
1Mbps with 1500 Bytes MTU?
I thought I need N*MTU recbuf so the pid will be able to handle a small
burst of UDP packets.
This is what I currently have:
gen_udp:open(0, [binary, {active, once}, {recbuf, 16*1024}])


On Fri, Jun 22, 2018 at 4:07 AM, Michael Stellar <unexplained@REDACTED>
wrote:

> Looks good, does these patch already being committed upstream?
>
> On Thu, Jun 21, 2018 at 8:56 PM Danil Zagoskin <z@REDACTED> wrote:
>
>> Hmm, seems like the value should be very close to expected size.
>> Setting buffer to 2048 did not change anything significantly.
>> The results in my previous message are with {buffer, 2048} option left
>> from earlier experiments.
>>
>> On Wed, Jun 20, 2018 at 8:06 PM Lukas Larsson <lukas@REDACTED> wrote:
>>
>>> On Wed, Jun 20, 2018 at 1:56 PM Jonas Falkevik <
>>> jonas.falkevik@REDACTED> wrote:
>>>
>>>>
>>>> Are you adding the multicast network to the loop back interface? Using
>>>> some other interface that does not allow multicast traffic?
>>>>
>>>>
>>> I though I had, but apparently not.... I managed to reproduce the test
>>> case now.
>>>
>>> I also spent some time staring at the code in the inet_driver and
>>> realized what the problem was in there. It would seem that a
>>> performance/feature fix for SCTP in R15B inadvertently introduced this
>>> behaviour for UDP :( I've pushed a bug fix to that problem in the
>>> inet_driver to the same branch. In my tests the scheduler utilization goes
>>> form 71% to about 4% with both patches. With the fix in the inet driver, my
>>> allocator patch does not really do any difference for this specific
>>> testcase, but I'll keep that fix anyways as it is a "good thing". I should
>>> probably also add a benchmark for this so that it does not happen again....
>>>
>>> I'd also like to add that changing the test-case to use a smaller
>>> user-space buffer also has the same effect. So if anyone is running a
>>> performance critical UDP server that has set the "recbuf" to a high value,
>>> I really recommend that you lower the "buffer" size to something close to
>>> the max expected packet size. In the example that Danil provided I applied
>>> the following patch:
>>>
>>> diff --git a/udptest.erl b/udptest.erl
>>> index 16a1798..4edeef0 100644
>>> --- a/udptest.erl
>>> +++ b/udptest.erl
>>> @@ -33,7 +33,9 @@ send_packet(ID, S, Addr, Port) ->
>>>
>>>  start_reader(Addr, Port) ->
>>>    GwIP = {0,0,0,0}, % {127,0,0,1},
>>> -  Common = [binary,{reuseaddr,true},{recbuf,2*1024*1024},inet,{
>>> read_packets,100},{active,500}],
>>> +  Common = [binary,{reuseaddr,true},
>>> +            {buffer,1500}, %% 1500 is just an example value, don't just
>>> copy this. You need to know what you max UDP packet size will be.
>>> +            {recbuf,2*1024*1024},inet,{read_packets,100},{active,500}],
>>>    Multicast = [{multicast_ttl,4},{multicast_loop,true},{ip,Addr},{add_
>>> membership,{Addr,GwIP}}],
>>>    Options = Common ++ Multicast,
>>>    spawn(fun() -> run_reader(Port, Options) end).
>>>
>>> and the scheduler utilization dropped to about 4% there as well.
>>>
>>> Lukas
>>>
>>>
>>
>> --
>> Danil Zagoskin | z@REDACTED
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180622/9c4a35cc/attachment.htm>