HP3000-L Archives

November 2000, Week 4

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:
"Johnson, Tracy" <[log in to unmask]>
Reply To:
Johnson, Tracy
Date:
Sat, 25 Nov 2000 00:04:00 -0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
> 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?"
>
> ***************************************
> Terry W. Simpkins
> Schaevitz Sensors Division
> Measurement Specialties
> [log in to unmask]
> 757-766-4278
> ***************************************
>

ATOM RSS1 RSS2