tkevans@fallst.UUCP (Tim Evans) (06/26/91)
I have been happily running CUTCP with the packet drivers on a
true-blue IBM AT with a 3Com 3C505 board for more than a year.
Recently, we came into some money and bought ftp Software's
PC/TCP, with Interdrive. Thinking that we'd soon want to integrate
Novell into the network, we ordered the packet driver version
of PC/TCP, along with the 3C505 version, just to be safe.
We have a couple of hundred identical machines and bought a
PC/TCP site license.
Well, when I started messing with PC/TCP *with* version 9 packet
drivers, I began having mysterious lockups of my AT during open
telnet (actually, 'tn') and ftp sessions. The machine required
a physical reboot to release the lockup. Sometimes, after such
a lockup and reboot, the machine would complain of a keyboard
failure (the keyboard was replaced, just to be sure, and this
had no effect).
During all the time I ran CUTCP on the same machine, I *never*
had a lockup of any kind.
ftp Software Tech Support recommended use of the NDIS driver
instead of the packet driver. They wouldn't exactly come right
out and say there is a problem with the 3C505 and their software
with the packet driver, but did insist that performance and
throughput would be better with the NDIS driver for the 3C505.
At their recommendation, I did install an NDIS driver, and this
did seem to solve the lockup problem.
All's well that ends well, I know, and I have to hand it to
ftp Software for sticking with this problem over the course
of a couple of weeks, but I nevertheless wanted to go over
this with this newsgroup to see what you might want to
say. (I'd even like to hear more from ftp Software.)
Let me say that I don't have any personal commitment
to either the packet driver or the NDIS driver (and don't
want to start a religious war on the subject); I don't
care what the ultimate solution to this problem is. Nonetheless,
having used CUTCP with the packet driver and having had no trouble
for such a long time, it seems, uh, curious that PC/TCP would have
this problem--given the fact that ftp Software is the keeper of
the standards flame for the packet driver.
Any and all comments welcome.
--
UUCP: {rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET: tkevans%fallst@wb3ffv.ampr.org
Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047skl@wimsey.bc.ca (Samuel Lam) (06/27/91)
In article <559@fallst.UUCP>, tkevans@fallst.UUCP (Tim Evans) wrote: >ftp Software Tech Support recommended use of the NDIS driver >instead of the packet driver. They wouldn't exactly come right >out and say there is a problem with the 3C505 and their software >with the packet driver, but did insist that performance and >throughput would be better with the NDIS driver for the 3C505. A while ago, James Van Bokkelen of FTP Software <jbvb@ftp.com> did say on the net that the Clarkson 3c505 packet driver has a problem (that's not easily fixable), and I think at that time he recommended the use of the 3C505-specific version of PC/TCP instead of the Clarkson 3C505 packet driver plus the packet driver version of PC/TCP. The problem as I understand it is that the Clarkson 3C505 packet driver utilizes the firmware on the board to do the real work, and that firmware has bugs, while the 3C505-specific version of PC/TCP download its own driver onto the board and thus bypassing the bugs in the 3C505's onboard firmware. I don't think the problem is with the packet driver version of the PC/TCP kernel. My own experience with the Clarkson 3C505 packet driver is that it seems to always lockup my AT after having moved a certain (large) volume of traffic. Your "keyboard failure" symptom seems to ring a bell too, but it has been a while since I last played with that setup... The performance of the 3C505 using the Clarkson 3C505 packet driver aren't great, but I have heard on the net that the 3C505 is capable of much better performance with the Novell Netware driver. Since I don't use Novell, I don't know what the actual difference is. I haven't tried the NDIS driver (and DIS_PKT on top of it) yet, but I do plan to try that out in the near future. ...Sam P.S. In case anyone want a few spare 3C505's, my company is getting rid of ours. They are used but functional, and we would let it go for much lower than what 3COM would charge for a new one these days. -- <skl@wimsey.bc.ca>
jbvb@FTP.COM ("James B. Van Bokkelen") (06/28/91)
Your summary of my previous posting is correct, and represents my best understanding of the situation. Our recommendation of the 3Com NDIS driver for the 3C505 is based on a guess that they would have either applied workarounds for the ROM bugs or downloaded code to fix them (possibly the same code as the 3C505-specific version of PC/TCP does, since we got that via a 3Com engineer who was disappointed in the performance of our LANWatch product in an early version that used the on-board ROMs). If I had to guess why CUTCP worked with the Packet Driver and PC/TCP failed, I would say 'timing'. We probably hit a timing window that CUTCP avoids, either through luck or because the developer of the 3C505 packet driver did more testing with CUTCP than PC/TCP. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901