Robert writes:
[...]
> The time to exchange packets over these connections is dramatically
> slower, usually 200 to 300 milliseconds.
>
> As some of these offices have increased the number of users of the app,
> they have begun to complain about the response time.  While the obvious
> solution is to upgrade the bandwidth,[...]

Minor nit: be careful not to confuse latency with bandwidth.  Network
performance is very similar to the classic response time versus throughput
relationship that underlies much of performance analysis.

> Our network manager has proposed another alternative.  He suggests
> setting up some NT Terminal Server systems in the computer room on the
> same segment as the HP3000's, and running the application on these NT
> systems.  Since only the keystrokes and display updates are going to the
> remote offices, the assumption is that this will work well and is lower
> cost over the long term than greater bandwidth connections.

The hazard here is that you may be increasing the sensitivity of your
application to latency by increasing the total number of packets that
have to be exchanged.  It's certainly not clear that doing all the
keyboard I/O (potentially at one packet exchange per keystroke) and
screen updates over the network would be less traffic than however the
application works now.  Even if you reduce the bulk volume of traffic,
your response time might not be any better because of the increased
number of times you have to pay the latency cost for each transaction,
and the increased overhead of a smaller average message size.

The proposed solution may very well be better than what you have, but,
like all performance issues, it's probably not as black and white as
it might appear.

G.