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.
K-

-----Original Message-----
From: Jaromir Dolecek [mailto:jdolecek@netbsd.org]
Sent: Friday, January 10, 2003 12:51 PM
To: kyle.unice@L-3com.com
Cc: tech-kern@netbsd.org
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

kyle.unice@L-3com.com 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
a
> 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
ms
> 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
dump
> 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 <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- 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.''     -=-