WIN-TCP Problem on 3B2/500
john.c.mc millan
duckie at cbnewsj.att.com
Thu Feb 28 09:03:37 AEST 1991
In article <1991Feb25.214152.27244 at prism.poly.edu> drubin at 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 at pegasus.att.com << Muttering for self, only
More information about the Comp.sys.att
mailing list