Re: Telnet over WAN latency troubleshooting

Rich Jordan <jordan@xxxxxxxxxxx> wrote:
> We're getting terrible latency on interactive telnet sessions.

Can you quantify that a bit?

> we've also tried the old culprit SET PROTO TCP/NODELAY with no
> perceived change in behavior (didn't expect any with that one,
> though; it was just worth a shot).

Was that done on both ends? Do you happen to have a packet trace of
one of the bad latency telnet sessions?

> Pinging from the Alpha to the remote decservers (through the tunnel)
> with 1200 byte packets I see zero packet loss except for peak time
> usage (~1PM to 6PM) where it rises to up to 5% (rare, 3% every day).
> Pinging to the remote DSL router LAN port (the gateway address for
> the firewall) I see about 1% less packet loss. Ping times are fine
> either way; about 120 - 140ms (small pings get through in 50-60ms).

If we assume that single characters are going-out as their own
segments, and being echoed by the remote, we can take the 50-60 ms as
the "no loss" time and calculate the chances of that happening as:

p == loss probability = 0.01 to 0.05
P packet not lost == (1-p) so 0.99 to 0.95

for a keystroke exchange that becomes 0.95^2 or 0.9, or 0.1 that there
was at least one retransmission. most TCP stacks have a minimum
retransmission timer of 500 milliseconds:

So, the average becomes

0.9 * 60 + 0.1 * 500 (I'm not trying to handle the cases where both
the keystroke and its echo are lost)

or

54 + 50 = 94 ms, which IIRC starts to be just on the hairy edge of
upsetting to someone who is a decent typist.

> I need to find out if there's any way to get telnet to work more
> efficiently over the link we have now. I don't see anything in the
> DNAS documentation that appears useful but I'm still digging. Are
> their any parameters in DNAS or TCPIP services for optimizing
> interactive (telnet) service over what is apparently a high (or at
> least sporadically high) latency link?

I'd double check that when you set tcp_nodelay it was on both ends and
actually took - via a packet trace. After that, you _might_ consider
lowering the minimum retransmission timeout if you "know" that it
remains above what one might expect for an RTT.

Might also see if the stuff connecting to the ISP network has some way
of prioritizing small segments (assuming the telnet traffic is mostly
small segments) over large stuff like HTTP or FTP etc.

rick jones
working off basic networking rather than vms knowledge...
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
.

Relevant Pages

  • Re: Cisco 1700 Config not able to processing internal webmail script
    ... So does that say when you try to telnet from the server by name, ... telnet destination is an external address so the packet will be routed ... to the ISP first- hop router and then back to your router? ...
    (comp.dcom.sys.cisco)
  • slow tps on NetWare
    ... databases. ... C Clear Physical Record[Unreassembled Packet] ... [TCP ... Retransmission] R OK ...
    (comp.lang.clarion)
  • FreeBSD tcp backoff problem
    ... I work on a stack which is derived from FreeBSD. ... but appliance does not receive it ... Since each retransmitted packet is acked, ... it is set to zero when the retransmission timeout happens. ...
    (freebsd-net)
  • Re: Atheros, hardware access layer, collisions
    ... >> I think there is still collision detection happening on the hardware ... I think I have to disable the retransmission of frames ... I've got two computers synchronized to send one packet each to this ... to each that it receives (on the application level, not in the control frame ...
    (freebsd-hackers)
  • Re: possible solution to performance issues with FTP client on HP3000
    ... I was under the impression that the first retransmission of a packet uses the initial interval, and the intervals grow longer after that. ... This is the lowest configurable values for these 2 variables (and yes the help documentation for "Retransmission Interval Lower Bound" is wrong... ... The first packet is sent out on a connection request and if no response, the second SYN at 2 seconds, the third at +4 seconds, the forth at +8 seconds, the fifth at +16 seconds, the sixth at +32 seconds, the seventh ... On local LAN links and extended links where the performance of an acknowledged TCP packet is on a smoothed average less than second the "Retransmission Interval Lower Bound" second will be the computed "Retransmission Timer" value. ...
    (comp.sys.hp.mpe)
Loading