HP3000-L Archives

February 1998, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Eric H. Sand" <[log in to unmask]>
Reply To:
Eric H. Sand
Date:
Mon, 9 Feb 1998 17:07:52 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (99 lines)
Just to shed a little light on this NT thread, please refer to an
article written
by Eric Hall over a year ago titled "Station Wagons And Operating
Systems"
in Network Computing Sept. '96. The proof is in the pudding!

http://techweb.cmp.com/nc/714/714colhall.html

                            Thx......Eric Sand
                                        [log in to unmask]



        >>Joe Geiser

        OK, Just to place my US$.02 into the ring...

        > I have first-hand experience with NT's poor performance, and
this is in
        > network processing, where one might reasonably expect NT to
excel. One of
        > the PC-based development projects I'm working on requires that
I keep the
        > source and object code on a separate server. A full 16-bit
build of this
        > project, about 1.5MB of source code, takes just under eight
minutes under
        > WinNT. I had planned an expensive upgrade for our network,
switching most
        > of our computers over to 100BaseT, thinking that was the
problem.
        > Fortunately, just before I started the upgrade, I had occasion
to boot
        > the development system under Win3.1 and perform the same task.
The
        > surprising result: 3-1/2 minutes to complete the same build,
from the
        > same server, on the same hardware. Simply switching to NT from
Win3.1
        > costs over 60% in performance in this admittedly rather
specialized task.

        First, I won't get into what Bruce was trying to do with NT
Workstation, but
        I can say this.  If running 16-bit code (even a 16-bit
compiler), it will
        run slower than on a native 16-bit OS in many cases.  (Remember
some of the
        16-bit apps compiled under MPE/V when brought over to MPE/iX
without
        recompiling?  Performance was slower in many (not all) cases.

        What I see in the paragraph above - it looks as though a 16-bit
app was
        being run or compiled under NT.  NT is fully 32-bit.  It's not
Windows 95
        (or even 98) where there is a bunch of "compatibility mode" code
in there.
        It's a wonder that it ran at all, but some of the 16-bit apps do
run under
        NT.

        Also, if using NetBEUI under NT, then there will be a
performance hit in the
        network arena.  TCP is clearly superior, and is supported under
3.51
        (limited) and 4.0 (rather nice and speedy stack).  MS is turning
over to
        TCP/IP and even Novell is ditching IPX in favor of TCP/IP
because it is
        superior.  Routing has nothing to do with it either, as NetBEUI
is
        non-routable and IPX is routable.  Both produce very small
packets and use
        many control packets to ensure that these small packets are
received, adding
        to the overhead.  Microsoft's implementation of TCP/IP, in many
respects, is
        superior to that of even some of HP-related vendors.  (As a
matter of fact,
        I turned off NetBEUI off a long time ago and use TCP/IP
exclusively).

        These two areas are issues to be dealt with as if using 16-bit
Windows (3.1,
        3.11/Workgroups) with an NT server, NetBEUI is needed, unless a
TCP/IP stack
        (like RNS, superior to MS' 16-bit TCP/IP stack) is added.
Windows 95 (and
        98) have no such limitation and can communicate to NT, including
the use of
        shares, URLs, and plain ol' Named Pipes and Sockets with TCP/IP
- with no
        need for NetBEUI.

        Again, my US$.02 worth, FWIW...

        Joe

ATOM RSS1 RSS2