If your remote users have internet access via their VPN (as opposed to
locally in the UK) you can determine whether or not the problem is with your
3k config.

If indeed their internet traffic can be forced through the VPN, then you
might go to www.dslreports.com, click on "tools", and run the performance
test against one of the US test sites.  Watch the progress report.  You can
also get tuning advice after running the test. With such large latency times
as you reported 250ms to 800ms, there are some registry entries you can
tweak that will increase throughput.

I'm also thinking that with such large latency times, character-mode
terminal i/o over the link will be very slow because each echoed character
must make the round-trip of half a second to 1.6 seconds.  For character
mode, I'd try turning on type-ahead.

-dtd

> -----Original Message-----
> From: Simpkins, Terry [mailto:[log in to unmask]]
> Sent: Wednesday, November 29, 2000 9:28 AM
> To: [log in to unmask]
> Subject: FW: FW: Serious Network 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.
>