ctw@aero.org (Charles T. Wolverton) (01/08/91)
Here's a variation on the FAQ "How can I get TCP/IP and Novell to work at the same time" - viz., "How ARE we getting them to work??" We are using a native (i.e., non-CMU/PD) IPX module talking directly to a 3C501. We are also using NCSA Telnet with the direct-to-the-card config (i.e., again, no PD). After carefully explaining to a colleague why, due to contention for the H/W IRQ used by the network card, he wouldn't be able to get Novell and NCSA Telnet to work simultaneously without a PD and the appropriate IPX-for-the-PD module, he proceeded to ignore this "wisdom" and load the Novell stack followed by the NCSA Telnet - works like a charm, apparently. (Specifically, he can log onto the Novell server, do some Telnet stuff, close the Telnet session, and the network drives are still there.) My assumption was that NCSA Telnet would grab the interrupt so that the IPX would be history. Hence, the question "Why does this work?? Does the NCSA Telnet do its own IRQ mux'ing?? or some other cleverness?? Or am I just way off base in my concept of what's going on?? (We also tried FTP'ing to the network drive - that DID bomb the machine as I would have expected.) -ctw *** Charles T. Wolverton ***** Aerospace Corporation *** *** ctw@aero.org ***** P.O. Box 92957 M1-023 *** *** (213) 336-5204 ***** Los Angeles, CA 90009 ***
dzoey@TERMINUS.UMD.EDU (01/08/91)
Your question is basically: "Why can I share a 3C501 card among non-cooperating applications when this behavior hangs other network cards?" The reason you can (sort of) share a 3C501 is that there is almost no state kept on the card. This makes it very easy for a second application to take over the card transparently from the first application without forcing a lot of state saving to avoid changing the first applications environment. The 3C501 can do this because it is a very simple card. No buffering, no scatter-gather i/o. I wrote (sort of) above because while applications can take turns using the card, I'm not sure two application can really share the card. That is, you may be able to load telnet off your novell network, but I don't think you could ftp a file to the novell drive. I may be wrong though as I haven't tried this. So, yes, it works for a 3C501, but the 3C501 is so slow and loses so many packets that you're usually better off getting a more recent generation card and using one of the many standard card sharing specs. Joe Herman U. of Md. dzoey@terminus.umd.edu
jbvb@FTP.COM ("James B. Van Bokkelen") (01/09/91)
We are using a native (i.e., non-CMU/PD) IPX module talking
directly to a 3C501. We are also using NCSA Telnet with the
direct-to-the-card config (i.e., again, no PD). After carefully
explaining to a colleague why, due to contention for the H/W IRQ used
by the network card, he wouldn't be able to get Novell and NCSA Telnet
to work simultaneously without a PD and the appropriate IPX-for-the-PD
module, he proceeded to ignore this "wisdom" and load the Novell stack
followed by the NCSA Telnet - works like a charm, apparently.
...
Hence, the question "Why does this work??
The magic word is "3C501". First, it has very little on-board state
(compared to something that uses an 8390 or 82586 LAN controller chip).
This makes it much more likely that the two drivers initialize it the
same way. Second, the card exists in various versions, and some (at
least) had quirks (to be charitable). If a 3C501 acts odd, or you don't
see traffic for a while, the first reflex action taken is to reset it.
In our "Compatibility Sheet", we note that PC/TCP has this kind of "cold
war" coexistence with many kinds of software when using the 3C501...
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901