drubin@prism.poly.edu (Dave Rubin) (02/26/91)
We are running Wollongong's WIN-TCP Version 3.0.1 on a 3B2/500 which is running System V Release 3.2.1. We are experiencing several annoying problems, most which have been around since the earliest versions of WIN-TCP: unstable network connections that are closed for no reason, daemon's (mostly sendmail) going into bad states, not accepting connections or producing file-related errors, streams functions failing on various programs, system crashes due to Kernel MMU fault, NFS/OpenLook totally broken. Lately we cannot even get sendmail to work at all (although it does work on another almost identical 3B2/500). Needless to say, the situation is unacceptable. 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? Any help would be appreciated... -- Dave Rubin Polytechnic University Brooklyn, New York
thad@public.BTR.COM (Thaddeus P. Floryan) (02/26/91)
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. > >We are experiencing several annoying problems, most which have been around >since the earliest versions of WIN-TCP: unstable network connections that >are closed for no reason, daemon's (mostly sendmail) going into bad states, >not accepting connections or producing file-related errors, streams >functions failing on various programs, system crashes due to Kernel MMU >fault, NFS/OpenLook totally broken. Lately we cannot even get sendmail >to work at all (although it does work on another almost identical 3B2/500). >Needless to say, the situation is unacceptable. >[...] Sigh. Looks like not much has changed since their version 1.4 for the 3B1. After some dorking-around with device driver loading, I have managed to find a configuration that "works" ... at least my sytstems have been up since November 1990 and I do a lot of 'net trafficking. HOWEVER: I had to trash a bunch of the "stock" WIN/3B stuff and port over parts of the networking software suite from 4.3BSD "Tahoe" (as found at UUNET), and some other 3B1-aficianados have ported over some other stuff. The WIN/3B sendmail and its daemon is total garbage ... would fill up the process table with defunct processes if one so much as sneezed in the same room, so I tossed it out the window and over the fence to accompany other bad software ... now I'm worrying the fence may collapse. :-) A colleague is bringing up a new sendmail (ported from the BSD world) for the 3B1 and this stuff "should" also work on the 3B2 (but I have NO way of checking). The 3B1 archive site is osu-cis (aka cheops.cis.ohio-state.edu) where you can find some of this stuff as well as in comp.sources.3b1 soon. If you have all the include files and socket library stuff, you may wish to try some of the 3B1 ports. No help possible with NFS, though, since that feature "level" never made it into the 3B1 product. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
duckie@cbnewsj.att.com (john.c.mc millan) (02/28/91)
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
ram@attcan.UUCP (Richard Meesters) (03/14/91)
In article <1991Feb27.220337.29559@cbnewsj.att.com>, duckie@cbnewsj.att.com (john.c.mc millan) writes: > - 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. > I was wondering if the version you were running was the original version I obtained from the States. But this confirms it. The release version of WIN TCP 3.2 has a switch in /etc/master.d/tcp caled 42COMPAT (or COMPAT42, I can't remember which way around) that defaults to the BSD4.2 window size. If you're going to run a network with 3.2 and 3.01 TCP/IP intermixed, you _have_ to set this and rebuild the system (Defaults to unset 42COMPAT = 0). Regards, ------------------------------------------------------------------------------ Richard A Meesters | Technical Support Specialist | Insert std.logo here AT&T Canada | | "Waste is a terrible thing ATTMAIL: ....attmail!rmeesters | to mind...clean up your act" UUCP: ...att!attcan!ram | ------------------------------------------------------------------------------