🚀 go-pugleaf

I had similar problems, and replacing the NIC in the server (by a
3C590) solved the problem.

Marcel


Chris.Tilbury@warwick.ac.uk (Chris Tilbury) wrote:

>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