Subject: RE: TCP behavior
To: None <,>
From: None <>
List: tech-kern
Date: 01/10/2003 12:53:01
Actually I do one large write on the server side of about 128K..  So there
should be no waiting for the user application to fill the socket buffers.  I
have also tried TCP_NODELAY and it did not help the problem.

-----Original Message-----
From: Jaromir Dolecek []
Sent: Friday, January 10, 2003 12:51 PM
Subject: Re: TCP behavior

Another idea - possibly NetBSD side is waiting for the socket
buffer to fill. Can you try if setting TCP_NODELAY option
for the socket on NetBSD side would help?

Jaromir wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> When using a TCP connection against a Windows Client we see the following
> behavior:  the window size is negotiated to 64K, the server (NetBSD) dumps
> large buffer (100K+) to the client (MS Windows).  The first two or three
> packet transmissions are back-to-back,  (no delay between data packets or
> windows ack) Windows (microsoft) sends an acknowledge.  NetBSD then holds
> off about a millisecond, then begins dumping data again, it gets two or
> three packets out and MSWindows sends an ack, again NetBSD holds off a
> millisecond and begins transmitting again.  We would hope to see NetBSD
> near a full window of data to the client before any delays in the
> transmission take place.  The MSS is negotiated to 1460.  The application
> does a single write for the entire buffer to the TCP socket.  We use
> setsockopt to set the rcv & tx buffer sizes to 128K. 
> Any help is appreciated,
> Kyle

Jaromir Dolecek <>  
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-