HP3000-L Archives

November 2000, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Simpkins, Terry" <[log in to unmask]>
Reply To:
Simpkins, Terry
Date:
Wed, 29 Nov 2000 16:28:05 -0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (55 lines)
We posted this a couple of days ago, but haven't gotten much response.
I thought I'd post it again and see if any of you data comm experts would
care to contribute some "insight/ideas/brilliance", etc.  We are stumped,
and so is our services provider.  Meantime I have some VERY unhappy users.

***************************************
Terry W. Simpkins
Schaevitz Sensors Division
Measurement Specialties
[log in to unmask]
757-766-4278
***************************************

We are having performance problems for some remote users on our HP3000.
All of our users are network connections (no Terminals).
All remote sites (3 in UK, 4 in USA) connect via Frame Relay.
The UK sites all share a single transatlantic PVC.  All of the sites in
the UK are experiencing SEVERE performance problems.  Noone in the USA
is having these problems.  Our first place to look was the transatlantic
PVC, since that is the obvious common thread.  We transferred the
transatlantic PVC to a VPN with signifianctly more available bandwidth.
While the PING times reported from the HP3000 to the remote site routers
decreased by 50% (now running about 250ms),
the response time as measured at the users PC (running Minisoft) say no
change. Why would PING times show a circuit that is fine, but still
response times at the "terminal" be so slow as to be unusable?
Ths problem seems to have appeared about 3 weeks ago.  Obvious question,
"what changed?".
The latest patches were applied Oct 22nd which were the General Fixes FTP
for 6.0 PUSH ("F" patch), and the General Fixes for TELNET ARPA Services
on 6.0 ("I" Patch).
Can anyone:
- provide any ideas on what would cause this?
- where we should be looking?
- the name of someone we can get to assist?
- should we remove the patches?

This problem has become so bad, the remote sites are sending people home
becuase they can't do their jobs.
Sessions get aborted (connection lost), spoolers are dropped, you get the
idea.
I have used SOS to monitor system load and see no problems, this is
reinforced by USA based users not seeing these problems at all.  We have
now changed the transatlantic link to a VPN, so we have removed that from
the list of possible culprits.  I have asked the provider to help us check
response time at each step of the way (each router).  They say this is a
very difficult thing to do because of routing tables, and are reluctant
since the PING time shows that there isn't a "capacity" problem.  The
question we don't understand is "what is the difference between a PING
packet and an NS/VT packet that could account for this?"  I ran PING from
the HP3000 specifying a packet size of 1514 bytes and the average response
time went from 250ms to 850ms ith 25% lost packets.  This tells me that
maybe things aren't so great on the frame relay circuit, correct?  The
250ms times were using the default 64byte packet sizes.

ATOM RSS1 RSS2