X-Envelope-to: NOVELL@SUVM.BITNET
X-VMS-To: IN%"NOVELL@SUVM.BITNET"
X-VMS-Cc: JRD
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.novell
Date:         Wed, 7 Oct 1992 23:16:39 -0600
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Joe Doupnik <JRD@USU.BITNET>
Subject:      Re: Weirdness

>    A cry from the poltergeist land. In July of 1991, we set up a
>Novell LAN w/286 2.2 Netware. Last month we upgraded to 386 3.11.
>Over the past year, I've run into quite a few strange & inexplicable
>problems that some network gurus on campus have ultimately attributed
>to 'ghosts in the machine'.
>
>Here's the basic setup:
>
>Server: 33/386 Dell w/8 Meg Ram & 330Meg Hard Disk, w/WD 16-bit e-net
>        card on Thin e-net attached to the campus backbone via a
>        CentreCom Repeater, Interlan Bridge & ChipCom Ethermodem III.
>
>Mailer: MegaTrends 286 Motherboard w/ AMI BIOS, 2Meg Memory in an XT
>        box w/Jameco controller card & ST-225 20Meg Hard Disk w/WD 16-
>        bit e- net card running Charon 4.0 software.
>
>Machine Topology: 20 asst. PC/XT/AT lab machines on thin e-net to the
>                  CentreCom Repeater.
>
>    75 asst. PCs faculty/staff machines using AUI
>    drops & 2 or 4 port transceivers with 8 & 16 bit WD(SMC) e-net
>    cards.
>
>    25 asst. Macs talking AppleTalk on LocalTalk using a GatorBox CS
>    as a Gateway to TCP/IP services and via Novell's Mac NLM, Novell
>    services.
>
>Mail Software:  PCs - Pegasus Mail 2.3r4
>                Mac - Pegasus Mail 2.0
>
>Here's the weirdness:
>
>    * Pmail Mac has a couple of problems.
>    1) Since 286->386 upgrade, Pmail 2.0 had to have it's home
>mailbox location changed to reflect the new mailbox/ids created by
>386 3.11 for user objects.
>
>    2) Users can't send to a Novell userid (recipient gets malformed
>messages, & 'sent' mail document remains on screen) but CAN send to
>full internet address via Charon Mailqueue. No, I haven't set PCONFIG
>to do this!
>
>    3) Intermittantly, users trying to send to an SMTP address are
>told they don't have an SMTP gateway, even though they do.
>
        <part omitted>
>    2) There's problems with some PCs & 8-bit Zeniths physically
>distant from the server. Performance is intolerable even for
>8-bit machines. These are Western Digital or SMC 8-bit cards & when a
>sniffer is placed on the line it appears as if the signal strength of
>the card is not enough to send acknowledgments to the server before
>the server times out.
>
>
>Whew, ... well, I'll pause & see what y'all have to say before
>getting more bizarre.
>Mark Edward Toomey                          mtoomey@hestia.fcs.uga.edu
>Computer & Network Support                  toomey@athena.cs.uga.edu
>College of Family & Consumer Sciences       mtoomey@uga.cc.uga.edu
>University of Georgia                       MTOOMEY@UGA
----------------------------------------------------------------------
        I think many of us would point the finger first at dropped packets,
from either an inadequate wiring plant or from too-slow clients, or both.
When packets disappear protocols can do some rather strange things. Thus
I would recommend getting the packets delivered properly as the initial step.
This means paying attention to the old XTs being able to cope with faster
servers, as well as correcting wiring troubles. This slow client, fast server
effect is essentially the same as dropped packets, because for the client
they are dropped. What's worse is some Ethernet boards go deaf for a few
minutes or so when overburdened with unread packets.
        Just as an example of this last comment. This week some DEC
workstations are blasting data across my wire in back to back 8KB chunks
(5+ Ethernet packets). My 8-bit WD8003E board has an 8KB buffer. Those
chunks plus normal net traffic overfill the board before it can be emptied
and the thing declines to work for a minute or two. A 16-bit and 16KB Ethernet
board carries on without a hiccup; an 8-bit classical 3C503 dies early on.
        I can suggest an experiment. ODI drivers are clever enough to want to
buffer incoming material at a fairly low level, if given a chance. They might
help your XT machines survive. The parameter of interest in NET.CFG is
        Link Support
                buffers 6 1514          6 max length receive buffers
The idea is to buffer low down rather than processing each incoming packet
through much of IPX and NETX and then fetching the next. I cannot state with
certainty that this will help your situation but it is worth a quick try.
        Joe D.
Xref: sparky bit.listserv.novell:15789 comp.sys.novell:8326