UDP thoroughput

Hello!

Sorry if it's a FAQ, but nevertheless:

Let's say I have a server that waits for UDP datagrams, and client that
sends 700 1000-byte datagrams as fast as it can over loop-back
interface. Upon receiving a datagram, server increments and prints a
counter. On average, only 75 datagrams arrive. If I add a timeout to
client, all 700 arrive. net.core.rmem_max = 8388608
Linux 2.6.13 i686
Is it expected behaviour? Is there anything to do about it?
My test code is below.

Thank you for any opinion,
Dmitri
(gone to read Stevens)

server:

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
int sock, length, fromlen, n=0;
struct sockaddr_in server;
struct sockaddr_in from;
char buf[2048];

sock=socket(AF_INET, SOCK_DGRAM, 0);
length = sizeof(server);
bzero(&server,length);
server.sin_family=AF_INET;
server.sin_addr.s_addr=INADDR_ANY;
server.sin_port=htons(1234);
bind(sock,(struct sockaddr *)&server,length);
fromlen = sizeof(struct sockaddr_in);
while (1) {
recvfrom(sock,buf,2048,0,(struct sockaddr *)&from,&fromlen);
printf("%d\n", n++);
}
}

client:

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
int i, sock, length, n;
struct sockaddr_in server, from;
struct hostent *hp;
unsigned char buffer[1095];

sock= socket(AF_INET, SOCK_DGRAM, 0);

server.sin_family = AF_INET;
hp = gethostbyname("localhost");

bcopy((char *)hp->h_addr, (char *)&server.sin_addr, hp->h_length);
server.sin_port = htons(1234);
length=sizeof(struct sockaddr_in);
for (i=0; i<1095; i++) buffer[i]=255;
buffer[0]=17; buffer[1]=0;
for (i=0; i<700; i++) {
sendto(sock,buffer,1095,0,&server,length);
/*usleep(1);*/
}
}

yavannadil wrote:

> Let's say I have a server that waits for UDP datagrams, and client that
> sends 700 1000-byte datagrams as fast as it can over loop-back
> interface. Upon receiving a datagram, server increments and prints a
> counter. On average, only 75 datagrams arrive. If I add a timeout to
> client, all 700 arrive. net.core.rmem_max = 8388608

You allow users to ask for bigger receive buffers.
Do you actually request a bigger receive buffer?

sysctl -w net.core.rmem_default=8388608
or setsockopt() in the app?

(E-Mail Removed) wrote:

> Hello!
>
> Sorry if it's a FAQ, but nevertheless:
>
> Let's say I have a server that waits for UDP datagrams, and client that
> sends 700 1000-byte datagrams as fast as it can over loop-back
> interface. Upon receiving a datagram, server increments and prints a
> counter. On average, only 75 datagrams arrive. If I add a timeout to
> client, all 700 arrive. net.core.rmem_max = 8388608
> Linux 2.6.13 i686
> Is it expected behaviour? Is there anything to do about it?

First, you MUST understand that UDP is not a reliable protocol. If UDP datagrams
arrive faster than you are receiving them, and the receive buffer fills up, then
datagrams will be dropped.

Second, standard IO like printf() is very slow and THIS is what is causing your
app to lose datagrams. You need to remove it from the receive loop.

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Phil Frisbie, Jr. <(E-Mail Removed)> wrote:
> First, you MUST understand that UDP is not a reliable protocol. If
> UDP datagrams arrive faster than you are receiving them, and the
> receive buffer fills up, then datagrams will be dropped.

In this context I'd probably put it that UDP provides no flow-control.

Of course, neither does it provide "reliability" a la TCP's "guranteed
notification of probable non-arrival" and TCP's attempts to retransmit
presumed lost data.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Ysgrifennodd Spoon:
> Do you actually request a bigger receive buffer?
> sysctl -w net.core.rmem_default=8388608
> or setsockopt() in the app?

No, I didn't, and now I do. Thanks a lot!!!

In fact, it turned out Stevens explained that same case. As they say,
RTFM.