Loay,
The window size in the TCP header is also 16bits long. It's not because of
NT4 that you can't configure for 65536.
Please note that in your formula you need to use the RTT (2*250ms), not only
250ms.
Regards,
Marcelo M. Reis
[email protected]
> ----- Mensagem original -----
> De: [email protected] [SMTP:[email protected]]
> Enviada em: Quarta-feira, 16 de Fevereiro de 2000 15:14
> Para: [email protected]; [email protected]
> Assunto: Re:Fwd:RE: nt to nt tcpsat problems
>
>
>
> Please note that a TcpWindowSize of 65536 in decimal value is
> 1 0000 in Hexadecimal. Win NT 4.0 does not realize this is and sets
> the window size to 0. When sending a packet to a host with a
> TcpWindowSize of zero, the host follows the TCP spec and sends back 1 byte
> to
> respond to the zero window size. The Win NT host then proceeds to
> advertize a
> no-zero window size and the communications begin. The rest of the packet
> which
> trails the initial 1 byte originaly sent is fragmented and minimizes
> throughput.
>
> To provide a band-aid fix, you can set 1 back the TcpWindowSize to 65535
> which
> is ffff in hex and does fit in the 16 bit tcp parameter.
> Windows advertizes correctly and communications is possible to a full
> theoretical
>
> 64 Kbyte * 8 bit/Byte / .250 ms(average sat delay) = 2.048 Kbit/sec
>
> Longterm fix - Use Solaris or Windows 2000 with the scaling option.
>
> Loay Oweis
> COMSAT Corp
> [email protected]
>
>
> ____________________Reply Separator____________________
> Subject: Fwd:RE: nt to nt tcpsat problems
> Author: Rob Kibler
> Date: 2/11/00 9:16 AM
>
>
>
> ____________________Forward Header_____________________
> Subject: RE: nt to nt tcpsat problems
> Author: <[email protected]>
> Date: 2/10/00 6:04 PM
>
> Gentlemen,
>
> I did a week long study on this exact problem and the simple answer is
> "YOU
> ARE OUT OF LUCK." I have a ticket open with MS on this problem as it is
> how
> the CIFS protocol works. CIFS will only negotiate a 4K transfer size when
> the latency and bandwidth are small (if you are very very ... lucky maybe
> upto 12K). Basically, in short your throughput will be about equal to
> 4K/RTT (excluding other various factors). Thus, window size only needs to
> be 4K for this. It is a higher layer problem!!!
>
> While I cannot give you a copy of my report, I do have a couple of graphs
> I
> can get to you.
>
> Greg
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Robert Schellhase
> Sent: Thursday, February 10, 2000 1:18 PM
> To: [email protected]
> Cc: [email protected]
> Subject: RE: nt to nt tcpsat problems
>
>
> Hi Graham,
> I see you have found that Windows supports a registry key for
> TcpWindowSize.
> The sad news is that it has no effect, in spite of the fact that Microsoft
> has a white paper on its own TCP implementation that claims otherwise.
>
> You might try the NetManage OnNet kernel for Windows 95/98 at
> http://www.netmanage.com/products/onnetkernel4/index.asp
>
> I don't know what they charge for it, but I think it's affordable and they
> offer a free demo.
>
> Best regards,
> Robert Schellhase
> Senior Engineer
> INTELSAT
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Graham Street
> Sent: Thursday, February 10, 2000 9:04 AM
> To: [email protected]
> Subject: nt to nt tcpsat problems
>
>
> Hi all,
>
> We're trying to run windows file sharing protocols over a tcp sat link
> and getting miserable performance, even after setting TcpWindowSize to
> 65536. We can get about 100-250k max. We are trying to get at least
> one megabit out of it. Is this even possible? We can get 1-2 megabits
> ftping from a sun box over satellite...
>
> does anyone know of any clever (cheap) solutions (spoofing nacks?,
> translating
> to udp?)
>
> Thanks,
> Graham Street
> [email protected]
>
>
> Received: from neal ([134.133.40.21]) by cqgate6.cmc.comsat.com with SMTP
> (IMA Internet Exchange 3.13) id 0000C4FC; Thu, 10 Feb 2000 20:34:37
> -0500
> Received: from [139.88.112.33] (helo=lombok-fi.lerc.nasa.gov)
> by neal with esmtp (Exim 2.12 #8)
> id 12J4w1-0002ND-00; Thu, 10 Feb 2000 20:31:49 -0500
> Received: (from listserv@localhost)
> by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA03975
> for tcpsat-outgoing; Thu, 10 Feb 2000 19:05:42 -0500 (EST)
> Received: from seraph3.lerc.nasa.gov
> ([email protected]
> [139.88.146.12])
> by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id
> TAA03944
> for <[email protected]>; Thu, 10 Feb 2000 19:05:40 -0500 (EST)
> Received: by seraph3.lerc.nasa.gov; id TAA20274; Thu, 10 Feb 2000 19:05:40
> -0500
> (EST)
> Received: from
> new-frontier-consulting-745192.cust-rtr.swbell.net(151.164.200.70) by
> seraph3.lerc.nasa.gov via smap (V5.0)
> id xma020153; Thu, 10 Feb 00 19:04:58 -0500
> Received: from houpdc.newf.com (mail.newf.com [216.62.131.2])
> by ns.newf.com (8.9.3/8.9.3) with ESMTP id SAA08636;
> Thu, 10 Feb 2000 18:04:54 -0600
> Received: from heliox (216.190.71.51) by houpdc.newf.com (Worldmail
> 1.3.167); 10
> Feb 2000 18:04:54 -0600
> Reply-To: <[email protected]>
> From: "Greg Otto" <[email protected]>
> To: "'Robert Schellhase'" <[email protected]>,
> <[email protected]>
> Cc: <[email protected]>
> Subject: RE: nt to nt tcpsat problems
> Date: Thu, 10 Feb 2000 18:04:20 -0600
> Message-ID: <000001bf7423$8bee7080$[email protected]>
> MIME-Version: 1.0
> Content-Type: text/plain;
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
> Importance: Normal
> In-Reply-To: <000001bf73fb$8f1de5b0$1615cad0@kensington>
> Sender: [email protected]
> Precedence: bulk
This archive was generated by hypermail 2b29 : Wed Feb 16 2000 - 13:57:29 EST