RE: Intermittent network failure

*AUTO/*AUTO on all gig. You must've missed my posts in the archive. ;)

Justin C. Haase
Solution Manager - Technical Services
Kingland Systems Corporation

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Roger Vicker, CCP
Sent: Tuesday, April 03, 2007 11:26 AM
To: Midrange Systems Technical Discussion
Subject: Re: Intermittent network failure

Jerry,

Interesting... Every other post I have from the archive says that both
ends should be hard configured because the negotiations don't go
smoothly.

I understand the power savings warning, but in this case where it can
and does hit several PCs at the same time if they are actually working
at the wrong point in time I doubt if it is related.

Thanks.

Roger

On 4/3/2007 9:57 AM, Jerry Draper wrote:

We had a similar problem except that it wasn't CA dropping it was the

i5

itself. We were configured at 100MB on the 400 and *auto on the

switch.

IBM had us apply a series of microcode ptf's to the ethernet adapter.
They recommended to put the i5 at *auto and the switch at *auto.

No problems since.

Jerry

PS: Beware that power saving options can cause emulation drops so I
leave "turn off disks" and "standby" at never.

J


Roger Vicker, CCP wrote:

Before I spend $2000 for new switches (probably Netgear's Prosafe

Smart

Switch series) has anyone got any diagnostic hints on this problem.

Model 800 at V5R3 with a Gigabit card (configured as 1G *FULL) to a

SMC

6624M stacked switch's Gigabit port (configured as Auto-1000, the

only

Gigabit option). XP Pro PCs running Client Access Express (CAE)
connected to the stack's 10/100 ports. New Cat5e patch cable tested

with

a medium-range network cable tester and installed for the Gigabit
connection.

Every day at least once, any CAE session that is actively talking at

the

wrong instant (not just sitting on a screen but sending/receiving)

will

fail. The system doesn't log anything to Qsysopr and in fact thinks

the

session is still valid. The CAE session seems to freeze for about

5-10

seconds then goes black and thinks it is disconnected. If you tell

the

CAE session to connect it gives an error that the device name is in

use.

The only solution is to wait until the TCP timeout expires (5

minutes)

or to use another session to DSCJOB the interactive job attached to

the

session.

The switch's event log shows nothing. The port counters show zero for
any of the bad things like drops and errors.

It can hit multiple PCs at the same time if they are at an active
send/receive function.

The time of day that it happens is not really predictable. Although

it

seems to cluster. Might hit for 5 minutes in the morning and not

again

till quiting time. It seems to only effect emulation (only protocol

that

is heavily used, no streaming audio/video...) but is not limited to

IBM

CAE as I am using Rumba and I get hit too. The one difference with

Rumba

(which does all communications through a single Engine) is that other
sessions on the PC will usually go in to *DSC status automatically.

Just

the unlucky session that was talking at the wrong moment is left

fully

active on the system. The Rumba Engine reports a communications error
and shuts down. Once the falsely active session is cleared all the

Rumba

sessions and Engine connect like normal.

Thanks.

Roger Vicker, CCP