Xref: utzoo comp.sys.att:11900 comp.protocols.tcp-ip:15078
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsj!duckie
From: duckie@cbnewsj.att.com (john.c.mc millan)
Newsgroups: comp.sys.att,comp.protocols.tcp-ip
Subject: Re: WIN-TCP Problem on 3B2/500
Summary: Upgrade is worthwhile
Message-ID: <1991Feb27.220337.29559@cbnewsj.att.com>
Date: 27 Feb 91 22:03:37 GMT
References: <1991Feb25.214152.27244@prism.poly.edu>
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 56

In article <1991Feb25.214152.27244@prism.poly.edu> drubin@prism.UUCP (Dave Rubin) writes:
>We are running Wollongong's WIN-TCP Version 3.0.1 on a 3B2/500 which is
>running System V Release 3.2.1.
:
>I have heard that version 3.2 of WIN-TCP has been released.  Does anyone know
>if this latest version fixes any of the problems stated above?  Or do I
>need to look into an alternative to these 3B2 systems that can't seem to
>behave themselves on the network?

Over the past 3 months our cluster of 3 3B2/700's has upgraded to 
WIN/3B r3.2 and SVR3.2.3.  The improvements have been enormous...
a several-fold reduction in hung processes and crashes.

These machines are cross-mounting [RFS] file systems and pound
the TCP interfaces pretty heavily at times.  There still are
crashes, but we're also running an extensive assembly of
packages, some of which are of local origin, so....  8)


I would STRONGLY recommend upgrading to BOTH SVR3.2.3 and WIN/3Br3.2.

The caveats...

	- Until this a.m., we were running Beta versions of
		WIN/3Br3.2.  I would EXPECT the now-available
		version -- by coincidence loaded onto one of our
		systems this morning -- to be at least as reliable.
		(As pevidence: that system hasn't crashed since!  8)

	- TCP under WIN/3Br3.2 seems to be argumentative with
		earlier releases: rumor has it that as a result
		of fixing a long-term bug regarding window-sizing,
		negotiation-arguments occasionally erupt between
		3.2 systems and earlier ones.  I've seen 99% of
		system CPU disappear for 30 minutes running.

		It's possible the now-available version has
		employed some strategy to counter this, but I'd
		confirm that, or convert all your 3B2's AND 386's
		at one time!  We did convert, and we're quite
		enthusiastic about the result.

	- SVR3.2.3 drops support of the "proc" driver -- 'tho'
		there's a rumor it might return.  (Do you use/
		require 'renice' or 'truss'?)

	- SVR3.2.3 defaults to 2KB logical block File Systems:
		you don't HAVE to convert your existing FS,
		but the KERNEL BUFFERS will be 2KB regardless
		of your FS, so that's 50% wasted RAM in the
		buffers if you don't convert some of your FS
		to 2KB logical blocks.

With pre-apologies for any errors in the above...

John McMillan -- >> jcm@pegasus.att.com << Muttering for self, only