Subject: RE: TCP behavior
To: None <jdolecek@netbsd.org, kyle.unice@L-3com.com>
From: None <kyle.unice@L-3com.com>
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.
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.'' -=-