lkml.org 
[lkml]   [2004]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPowers-of-two - 7 for recv() length??

Linux version 2.4.24

Given a TCP/IP server feeding data as fast as it can
to a stream connection on a dedicated link, and a
client receiving that data, I observe that the data
received is usually a (power-off-two - 7) bytes in
length, followed by the 7 bytes returned by the next
recv() call.

It makes no difference if Nagle is turned OFF (TCP_NODELAY).

Very bad!
Recv value was 114681
Remaining length was was 409607
Very bad!
Recv value was 7
Remaining length was was 0
Very bad!
Recv value was 65529
Remaining length was was 458759
Very bad!
Recv value was 7
Remaining length was was 0
Very bad!
Recv value was 65529
Remaining length was was 458759
Very bad!
Recv value was 7
Remaining length was was 0
Very bad!
Recv value was 65529
Remaining length was was 458759
Very bad!
Recv value was 7
Remaining length was was 0
Very bad!
Recv value was 65529
Remaining length was was 458759
Very bad!
Recv value was 7
Remaining length was was 0
Very bad!
Recv value was 65529
Remaining length was was 458759
Very bad!
Recv value was 7
Remaining length was was 0
Very bad!
Recv value was 65529
Remaining length was was 458759
Very bad!
Recv value was 7
Remaining length was was 0
Very bad!
Recv value was 65529
Remaining length was was 458759
[SNIPPED....]

Code snippet:

len = BUF_LEN;
while(len)
{
if((ret = recv(s, cp, len, 0 )) <= 0)
{
if(errno == EINTR)
continue;
handler(0);
}
len -= ret;
cp += ret;
if(ret & 1)
{
fprintf(stderr, "Very bad!\n");
fprintf(stderr, "Recv value was %d\n", ret);
fprintf(stderr, "Remaining length was was %u\n", len);
}
}

Given that the transport sends only even numbers of bytes, I
would guess that there is considerable overhead associated with
the 7-byte break. This likely points to something being
broken and some work-around incorporated to "fix" it. The
additional calls necessary to receive a mere 7 bytes into
a buffer that expects to get filled with 1/2 megabytes,
seriously reduces the through-put, not only because of the
additional call, but because of the remaining odd-byte
buffer alignment necessary for the next recv() call.

Could somebody who understands the network code please
find out what is going on. I can't find Alexy who used
to handle these kinds of problems off the list.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.114 / U:1.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site