当前位置: 动力学知识库 > 问答 > 编程问答 >

c++ - Execution time for Winsock function too long

问题描述:

I have a application running on a Windows XP platform (i7 2.1 Ghz processor). This application is a master/slave based communication between master and slave nodes, over UDP.

The master sends a request and slave node sends in its response (Burst Mode), packets of data every 5 ms, each data packet 1300 Byte long including header.

Back in the master node the main thread receives the data and writes it to a queue, triggering a parallel thread to read out from the thread.

Problem:

The execution time for the Winsock API is very long while reading the next packet, and so the data is being lost from the buffer.

Execution time: Recvfrom() - 200 - 400 Microseconds.

Open_Sock ()

{

socket();

//Error check

connect ();

//Error Check

}

Receivethread()

{

sock again:

select(socket, read,write,excep,(0,0));

//error check

rc = recvfrom(socket,buf,len,0,&s_addr,&cln_alen)

if(rc>0) {

enqueue(queue,buf);

}

}

I am sure the Winsock API does not require such a long time just to fetch the next packet.

But I cannot find any information on what the real execution times should be. Any help in the direction is really appreciated.

网友答案:

You probably hit the combination of sending/receiving buffer size and OS scheduler issues. On Windows platform context switch between threads is not too frequent, so there are two options which you can use:

  1. Increase priority of the server process

    This will reduce time your server application is staying in the queue.

  2. Increase the receiving buffer size

    You need to do it on both ends. You can use setsockopt with SO_RCVBUF option:

    int size = 1 * 1024 * 1024;
    setsockopt(socket, SOL_SOCKET, SO_RCVBUF, (const char*)&size, sizeof(int));
    
网友答案:

If losing packets is an issue, use TCP. Using TCP, I achieved a response time of less then one millisecond on a less modern machine for a simple loopback connection. Some important points there:

  • Use WSAEventSelect() in combination with WaitForMultipleObjects() when waiting for traffic. I'm not sure if this makes a big difference compared to select(), but it makes handling easier if you want to stop the thread with an additional event.
  • Allocate a buffer before waiting for input, this reduces latency a bit still.
  • Try to not create a thread for each packet but have threads waiting already, i.e. use a thread pool.
  • Try to send as few packets as possible, i.e. try to assemble the whole data in memory and send it with a single call. This avoids the network IO overhead for multiple packets that are assembled lateron.
  • Also take a look at the Nagle Algorithm, which you will probably want to turn off for TCP. The Nagle Algorithm in combination with a delayed acknowledge can seriously affect your latency.
分享给朋友:
您可能感兴趣的文章:
随机阅读: