Browser speed a function of TCP/IP stack?

Browser speed a function of TCP/IP stack?

Post by Nolan W. Eva » Thu, 17 Aug 1995 04:00:00



I am comparing the performance of Netscape 1.1 for Windows to that of
Netscape 1.1 for HP-UX and I find that downloading a certain page off
our internal web server to the Windows machine takes 20 seconds while
on the HP-UX workstation it takes 2 seconds. The Windows download
peaks at about 2.5 kbytes/second while the HP-UX download gets up to
60 kbytes/second.

I am using the latest Novell Lan WorkPlace TCP/IP stack on a 486DX33
with 16MB RAM and both the Windows machine and the HP-UX workstation
are on the same subnet.

Are these numbers the best I can expect from a Windows browser or
would a better stack (a VxD stack perhaps) improve them?

--
Nolan W. Evans                                ___   Department of

                                    / | / | /--     University of Guelph
(519) 824-4120, ext.3696           /  |/  |/___     Guelph, ON, N1G 2W1

 
 
 

1. MS TCP/IP Stack vs. NeXT TCP/IP Stack

Hello everyone,

I have an unusual problem and I wanted to see if anyone else could
explain or validate what I'm experiencing.

I work in a NeXT environment with a mixed bag of clients running
NeXTStep on both NeXT and Intel hardware, in addition to a few NT 3.51
Workstation clients.  I've recently put up an NT server (3.51 with SP5)
that acts as a Lotus Domino HTTP server.  Users running NT Wks have no
problem hitting the WWW server using either Netscape or IE.  But users
running Next (on either platform) experience significant delays when
hitting the WWW server with their NeXT-based browser (OmniWeb).  I hung
a sniffer off the backbone and captured packets traveling between the
server and the two different clients, and this is what I saw:

1)  Problem #1 - The request coming from the NeXT client to the server
always specify that the packet window size for all NeXT clients be set
to 4k.  I've been told that is set in the kernal on the client, and can
not be changed.  Whereas the packets for the NT client is dynamic and
can be up to 32k.  I chalk this problem up to a limitation on the NeXT.

2)  Problem #2 - It appears that whenever a request arrives at the
server from a NeXT client, there is ALWAYS an average delay of about 3.5
seconds before an ACK is ever sent out.  But whenever a request arrives
at the server from an NT client, the delay is minimal (usually about
250ms).  Is there some sort of incompatibility between the two stacks?
Or is Microsoft's stack on the server "seeing" that the NeXT request
does not have NetBios encapsulated in it (like MS's stack does), and
therefore figures that it is not a MS stack and "slows down" the
process?

Either case, it looks like there isn't much I can do to fix the lag, but
I was just wondering if anyone knows if my results are standard for the
MS stack, when running with other vendor's implementation of TCP/IP.

Ron Blankenship, MCSE
Sr. Network Engineer
Integrated Data Systems


        or

2. Windows Media Format SDK, encoding settings

3. Access TCP-IP hosts thru RAS/NT - no TCP-IP stack

4. Fragmentation problems

5. WWW BROWSER with own TCP/IP stack?

6. lost my standby Win'98

7. Stack overflow error in winsock/microsoft tcp/ip stack

8. Can't Connect Windows 95 Client to NT 4.0 RAS Server

9. TCP-IP Tip - Sped up my web browser, etc.

10. TCP Sequence Prediction in NT TCP/IP stack

11. IP Multicast support in Windows TCP/IP stacks?

12. Any TCP/IP stack for PC supporting IP Multicasting?

13. Trying to setup notebook with MS TCP/IP-32 and Chameleon IP stack...