large average round-trip

[Franky Leeuwerck_2]

Hi all,

I want some on advise on network performance.
I have two servers, about 700 miles away from each other, connected with a 1 Mb line.
Tens of users are using the line for all kind of client/server applications.

Very regurarly and for several minutes, I see large average round-trip times between 500 and 1000 msec's.

Can someone tell me what acceptable round-trip times are ?
From what round-trip time, are users experiencing a 'slowness' in response times ?


Regards,
Franky

[rick jones]

Q: How long is a piece of string?
A: It depends.

Same thing here. An acceptable round-trip time depends entirely on the applications and their users. FTP transfers probably don't care so much about RTT unless they don't have a large enough TCP window. Someone sitting in an editor typing might indeed care about a 1 second RTT. If they are just sitting in a forms application that normally has a multi-second response time they may not care.

I suspect that when you have the long RTT's you have high utilization on the link and deep queues at one end or the other of it.

[Franky Leeuwerck_2]

Thanks Rik.

Also now and then, but it is occuring less frequently and for shorter intervals, we also see some packet loss (10% .



Franky

[rick jones · Accepted solution]

10% is not just "some" packet loss. For protocols such as TCP that is _huge_.

Consider the case when you have a synchronous request/response application, and the normal RTT is say 50 milliseconds. Often as not, the minimum TCP retransmission timeout is 500 milliseconds. If we assume that 10% of the packets on the network are lost and that the request and the response are each a single TCP segment, then for the transaction to have no RTT delay it means that both the request and the response have to have made it through without a retransmission. That means a probability of 0.9*0.9 or 0.81. This means that 0.19 or 19% of the transactions will have at least 500 milliseconds added which yields an average latency of:

0.81*50 + 0.19 * 500
40.5 + 95
135.5

that 10% packet loss on the network is tripling the average response time in that example. If the non-loss RTT were 100 ms then it would be nearly doubling it etc etc...

In short (finally :) a 10% loss rate on a link is doubleplusungood.

[Bill Hassell]

The first step is to verify the specs on the 1 Mb network line. Does the supplier provide any reliability and performance specs? Is this a shared line (like a cable modem?). You can't really change anything in HP-UX to improve these delays if they are indeed occuring in the communications link. The packet loss seems to indicate that the network link is unreliable.

[rick jones]

Unreliable, or perhaps overloaded.

TCP (I'm ass-u-me-ing TCP is the dominant protocol) congestion control is one thing, but with enough "mice" (eg short connections or connections where the exchanges are small numbers of segments) there is only so much it can do.

Also, and off the wall question - there is no chance that this link to go 700 miles doesn't sometimes get routed through a satelite?

[Franky Leeuwerck_2]

Thanks for your inputs.

The line was surely unreliable and I've contacted the supplier. Have no idea about the specs: I am a 3th party that wants to make sure that the apps respond fast enough.

Satelitte connection ? Could be .

Best regards,
Franky