🚀 go-pugleaf

ddbs2@aol.com (DDBS2) wrote:

[snip]
>The second problem we have is copying files from a network drive to the
>local hard drive.  After copying about a megabyte or more of files, the
>machine seems to hang, but the mouse is still active.  A CTRL-ALT-DEL 
>brings up the message that the machine is busy or unstable (WFW v3.11
>on DOS v6.22). 

I've seen this; it happens between my workstation (a P166 system with
a 3Com 3C509B) and our server (which is a P75 with a 3Com 3C579).

I can recreate the problems easily, and with two different results,
depending upon Client32's configuration.

The first case, when using the 32bit LAN drivers, causes the machine
to hang during periods of intense network activity. This is with the
3C5X9.LAN that's included with the Client32 DOS/Windows distribution.
As in your case, the message about the system either being busy or
unstable appears when you perform the old 3 fingered salute.

In the second case, when using the 16bit LAN driver, the machine
doesn't hang - rather, a modal dialog box appears in the middle of the
screen with words to the effect that [application name] is retrying
requests to forest - press ok to return and error and let client32
retry in the background. Leaving this for a little while causes the
dialog to disappear and things to continue as normal.

The former may be a problem with the 3Com 32bit LAN driver (I've seen
reports that for some reason, it has difficulty reconnecting). The
latter though, is also reproducible when I exchange the 3C509 for an
Intel EtherExpress card (I've never tried the 32bit LAN driver for the
EtherExpress) and use EXP16ODI.COM.

The Novell support database has a TID number 2911651 ; "Client32 locks
when using COPY with Netframe". The jist of this document is that
client32 is able to transmit packets faster than other
stations/servers can process them. When Client32 blasts packets at a
slower NIC/server this can cause connection problems (disconnecting
them or even locking the local PC). Because NETX (and presumably the
VLMs) were slower, this wasn't likely to arise.

This appears consistent with what I've been seeing - the message about
attempting to reconnect to the server, etc.

The solution (allegedly) is to change the server Maximum Physical
Receive Packet size at the server, increasing it; by doing this, you
make fewer but larger packets, which the server can hopefully deal
with more effectively (this can't exceed the cache buffer size,
according to the TID - or in other words, the smallest block size of
any volume on the server).

The reason I say allegedly is that I've done this (gone from 4202 to
8192, as far as I can) and it's still happening. I'm tempted to
replace the 3C579, which isn't the nicest card in the world, but am
reluctant to do so without some concrete evidence that this is going
to actually resolve the problem. I've also upped the minimum packet
receive buffers from 100 to 200. I am very concerned about what's
going to happen if I go live with this on other systems and they all
start to outperform the server during periods of heavy network
activity.

(The default packet size for Client32 appears to be 4736).

>Hitting escape brings us back to a screen with the top 
>quarter blacked out.  We are using regular VGA drivers...
(as it happens, this last bit isn't really important)

Anyone else run into this? And have some suggestions?

Cheers


Chris