[erlang-questions] UDP client/server performance

[Ronny Meeus]

Hello

Thanks for taking the time to run the examples.
I have run the tests also on a different machine and there is see also
better results so it looks like there is an issue with the beam
running on the first machine. Maybe it is compiled with different
options ...
Anyhow, I will continue the development of my application based on
Erlang since I like the mechanisms it offers (threading, messaging,
error handling etc) a lot. I initially wrote the mail because of the
huge difference in performance I saw.

Ronny

On Sat, Aug 18, 2012 at 3:52 PM, Dmitry Kolesnikov
<dmkolesnikov@REDACTED> wrote:
> Hello,
>
> I would slightly disagree with your evaluation approach on UDP performance. It is obvious that Erlang code is slower to compare with C code. Therefore, any single threaded benchmark would always show a highest performance of C code. You have to push it in multi client env... I've re run you test cases and got a bit different results with vanilla gen_udp.
>
> So, the lowest latency of inter packet arrival time on Erlang is about 16-17 usec. This is the time used by underlying SW stack to process packet and deliver it to application process. I did not managed to get any lower latency on my hw (Mac Lion Server).
>
> Async case: pure C solution handled about 341K packet/sec, erlang server runs 256K packet/sec. One of the biggest problem for async is high packet drop rate in both C & Erlang cases.
> Sync case: pure C solution handled about 160K packet/sec, erlang server runs 45-50K packet/sec.
>
> Regards, Dmitry
>
> On Aug 15, 2012, at 5:03 PM, Michael Santos wrote:
>
>> On Wed, Aug 15, 2012 at 09:59:22AM +0200, Ronny Meeus wrote:
>>> On Wed, Aug 15, 2012 at 2:53 AM, Michael Santos
>>> <michael.santos@REDACTED> wrote:
>>>> On Tue, Aug 14, 2012 at 10:10:57PM +0200, Ronny Meeus wrote:
>>>>> Hello
>>>>>
>>>>> thanks for the info.
>>>>> I'm currently playing with the procket and it is working well.
>>>>>
>>>>> I have 2 questions:
>>>>>
>>>>> - I need to run the erl as root (or use sudo to start it) or I get:
>>>>>
>>>>> 2> {ok, FD} = procket:open(53, [{protocol, udp},{type, dgram},{family, inet}]).
>>>>> ** exception error: no match of right hand side value {error,eperm}
>>>>
>>>> Make priv/procket setuid or allow your user to call priv/procket using
>>>> sudo.
>>>
>>> I tried all options mentioned in your readme already before but non of
>>> them seem to work on Ubuntu. I think there is an issue with the sudo
>>> stuff on this distribution since no matter what I do, it always ask
>>> for a password when the procket command is executed.
>>>
>>> Now I succeeded by explicitly specifying the name of the program to use:
>>> procket:open(53, [{progname,"/usr/local/bin/procket"},{protocol,
>>> udp},{type,dgram}]).
>>
>> procket uses priv/procket as the default path. Sorry, README should be
>> clearer.
>>
>>>>> - How do I use recvfrom/4 in the server? If I call recvfrom/4 when
>>>>> there is no message present in the socket, it returns an error since
>>>>> the socket is put in async mode.
>>>>
>>>> Yes, the socket has to be non-blocking or it will block the scheduler.
>>>>
>>>>> Does this mean that the socket needs
>>>>> to be polled by the Erlang process or is it possible to get a
>>>>> notification (msg) when there is data present in the socket so that
>>>>> the recvfrom/4 can be called at that moment?
>>>>
>>>> You could plug the fd back into gen_udp:open(Port, [{fd, FD}]) ;)
>>>>
>>>> For a UDP socket, I can't think of any options other than the ones
>>>> you've mentioned: either spin on EAGAIN or use another NIF to notify you
>>>> when the socket is ready. There are a few ports to libev and libuv around.
>>>
>>> OK I will look around.
>>> Thanks.
>>>
>>> Yesterday I did a quick test and created an application that once it
>>> receives a message, it starts to send this back in a loop.
>>> It looks like it is able to send almost 200Kpkts/sec on a low end PC
>>> while the gen_udp solution only was able to send something like
>>> 10Kpks/sec on a much more powerful PC. So it looks promising ...
>>
>> That's cool! But remember, the C and the Erlang examples you posted are
>> doing different things. The C code is single tasking. It doesn't do any
>> error handling either. The Erlang code is multitasking, switching
>> between processes, monitoring processes for failure, ....
>>
>> If you run C NIF code in a tight loop, you'll get something closer to
>> the single tasking C code at the expense of concurrency. Maybe that is
>> fine for your needs though. Anyway, good luck in hitting your numbers!
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>