Performace issues using UdpClient.BeginSend / EndSend RRS feed

  • Question

  • Hi,

    in our software (C# .net 4.7.2) we are using a UdpClient to send data asynchronously to several targets (about 120 target devices). We need to send about 300gbit/sec over one gbit network adapter and that works somehow so far. It's basically some kind of video output that we send with 30fps to some controllers which send the intensity values to the pixels. So timing is an issue here.

    Here is how the send thread basically is implemented (i stripped it down a little bit):

    while (_active) { int sendBatchResult = SendDatagrams(); if (_readyDataCount == 0 || sendBatchResult == 0) { Thread.Sleep(2); } } private int SendDatagrams() { while (cnt < _readyDataCount) { _client.BeginSend(data.Data, data.Length, datagram.Destination, _sendCallback, data); } }

    //the _sendCallback: private void HandleSendResult(IAsyncResult result) { _client.EndSend(result); //return the buffer into the pool for reuse ((ValueBuffer<byte>)result.AsyncState)?.Release(); }

    Now the problem that we are facing is that the send-thread has a very high CPU load and from time to time the udp send is interrupted for more than 100ms (sometimes 400-500ms).

    The thread priority is set to highest.

    I analyzed the application with Jetbrains dotTrace and it seems that BeginSend takes quite a long time and in the BeginSend method the OverlappedCache.ctor takes most of the time:

    42% OverlappedCache..ctor

    28% DoBeginSendTo

    26% Sleep

    Rest not noticeable.

    We have written a small benchmark application that we've run on the same PC and it reaches about 900mbit/sec with a very low cpu load. We also checked the benchmark application with dotTrace and the OverlappedCache.ctor didn't even popped up in the analysis (with the difference that the benchmark app sends 1:1 not 1:N).

    Are we hitting some limitations in the network stack (OS, network card driver, buffer sizes, etc.)? Some idea how to fix that or at least some workaround?

    Tuesday, January 22, 2019 5:41 PM

All replies

  • Hi Andreas Spernol,

    I think you are right. it may hit some hardware limitations. In my opinion, It could be that hardware limitations are causing the IO to take up too much CPU to read and write. In general, a hard disk can only read and write at 100MB/s, and there are also network cables.
    Due to the complexity of the actual network environment, the effect of using udpclient will be worse. I suggest you use block transmission.
    Best Regards

    Tuesday, January 29, 2019 9:26 AM