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 ]
cage@cbnewsd.att.com (charles.gerlach) (02/27/91)
Folks: Here we go again. Trashing products based upon rumors, innuendos, and mis-information. I empathize with your 3B1 dilemma, but to compare that to the current AT&T WIN/3B product is wrong. The 3B2 product was produced by TWG approximately 4 years ago as a totally separate product from the 3B2 and 386 lines. Since then there have been 3 major releases of the other lines (R2.1, R3.0.1/R3.0, and R3.2). I just checked with AT&T's support organization and Release 1.4 is the current 3B1 WIN product. Its my understanding this product is not under active development, so R1.4 is all there every will be on the 3B1. Now to get back to the original question. Around Christmas, Release 3.2 of WIN/3B and WIN/386 became generally available. This release consolidates the available R3.0.1/R3.0 patches and other changes to improve the functionality of the products. Release 1.2 of NFS is also available. To upgrade from a previous release, please contact your AT&T support organization or your salesperson. If they have any problems, tell them to contact the product manager, Tim Trautman, for information on the upgrade procedure. Chuck Gerlach cag@iwlcs.att.com
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 | ------------------------------------------------------------------------------