Just throwing this out. Probably not it, but who knows. Are you taking
into account the transatlantic cable that was cut near Australia? This was
the major internet backbone cable in the area. To compensate they had to
reroute traffic. If you were on the backbone then you would be affected,
but even if you weren't, it is possible the additional traffic of the
reroute is affecting you? This supposed caused all kinds of problems.
-------------------------------------------------------------
Gary L. Paveza, Jr.
Technical Services Manager
(302) 761-3173 - voice
(877) 720-2970 - pager
-----Original Message-----
From: Simpkins, Terry [SMTP:[log in to unmask]]
Sent: Wednesday, November 29, 2000 11:28 AM
To: [log in to unmask]
Subject: [HP3000-L] FW: FW: Serious Netowrk problems
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.
|
