Our experience before we migrated was that the HP3000s were the first to
freak out when ANY change was made to the network.   A reboot always
solved the problem !  

Actually many years ago, we did have one problem with the HP3000 that
was resolved by a configuration change on the HP3000.   Our operations
manager explained the problem to me at the time but all I can remember
is a general description (as I am not a network guru). Essentially the
HP3000 was sending its network requests using a slightly different
protocol to the other systems on the network,  and that all the other
systems' requests were processed at a higher priority than the HP3000.
The bottom line was we had the same symptoms - intermittent packet loss
etc.    Using the same protocol on all systems resulted in all network
requests being processesd with the same priority and the problem was
solved.  
 

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Jeff Kell
Sent: 29 July 2011 03:33
To: [log in to unmask]
Subject: Re: [HP3000-L] Deteriorating Network response times

On 7/28/2011 8:30 PM, Mark Ranft wrote:
> While setting timers is important. It doesn't explain the
deterioration.  My bet is the switch port setting is not 100 full. This
would explain why the network would still work. And there is a slow
down.  I also bet pings would drop packets. 

With mismatched duplex, both sides will see errors, just different
types.  The Linkcontrol stats are relatively clean, other than received
address drops.  The percentage of broadcast packets is rather large
relative to unicast, but maybe this is just a busy segment with
relatively little 3000-destined traffic (?).  Since the 3000 side is
100/full, I would expect CRC errors or similar (TCP retransmits, which
Linkcontrol won't tell) when the switch side "detects a collision" and
stops transmitting and/or retransmits.

Were you doing pings from the same subnet, or a different one?

You have two active network interfaces.  What does your routing look
like?  Are your gateways as expected (you may have had redirects, which
the 3000 honors, but never forgets).  You may have some asymmetric
routing taking place (received traffic on one interface being answered
on another).  Or iss one of the interfaces "strictly" a local subnet
with no gateway?

If pings are that unreliable, there is packet loss somewhere, but it
doesn't appear to be on the 3000-to-upstream hop.  Once you get packet
loss, then the default timers can really exaggerate the delays.  Fixing
the timers may reduce the delays, but won't eliminate the packet loss.

Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

The contents of this email are confidential to the intended recipient and may not be disclosed. Although it is believed that this email and any attachments are virus free, it is the responsibility of the recipient to confirm this.

Details of Smith & Williamson group companies and Nexia Smith & Williamson Audit Limited and their regulators (where applicable), can be found at this URL

http://www.smith.williamson.co.uk/disclosure

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *