telnet delays

Running RHEL 3.0 on a dual cpu intel box. I have users (about 10-15)
using telnet to access an app called Pick. Telnet is the only option, as
Pick can't "do" ssh, etc.
That said - they seem to be having significant keystroke delays at
different times of the day(press "K" wait a second, press "I",
wait...etc). They are telnetting over a broadband(dsl or idsl)-based
vpn. Most of the time, all is well, but every other day, they have the
same kind of delay.
It is not isolated to a particular PC or geographic location (two
offices - the only two, in different cities). AND - those on the
internal network, where the server is located, do NOT have that problem.

My first reaction was that it was because of the dsl, but that can't be
because two offices 75 miles from each other are having the same problem
at the same time - has to be an internal problem. The main office(server
site) is 192.168.1.x, and the offices are on 192.168.30.x and ~40.x

Any ideas? Any tips/tools on troubleshooting this?

Thanks - D

> they seem to be having significant keystroke delays at
> different times of the day(press "K" wait a second, press "I",
> wait...etc).
> those on the
> internal network, where the server is located, do NOT have that problem.
>
> My first reaction was that it was because of the dsl, but that can't be
> because two offices 75 miles from each other are having the same problem
> at the same time - has to be an internal problem. The main office(server
> site) is 192.168.1.x, and the offices are on 192.168.30.x and ~40.x

It doesn't have to be internal - for example, it could be a sluggish
router on whatever path the two routes have in common.

Things you might try
- install some good network monitoring software
- look at all hardware under your control and make sure you're not
having hardware problems somewhere (firewall, border router, ...). I'm
thinking high error counts here. I don't think this matches the pattern
you are seeing, but it never hurts to be thorough.
- run a low frequency ping (or udpping; need to turn the echo port on)
from both remote systems and see if you get delays at the same time.
- run same to another system and see if you get delays at the same time
(unless you are 100% sure it's not a server problem).
- capture traffic at the clients and determine if packets are being dropped.
- capture traffic at both ends and measure one-way delay. (hard problem)

Allen McIntosh wrote:
>
>> they seem to be having significant keystroke delays at different times
>> of the day(press "K" wait a second, press "I", wait...etc). those on
>> the internal network, where the server is located, do NOT have that
>> problem.
>>
>> My first reaction was that it was because of the dsl, but that can't
>> be because two offices 75 miles from each other are having the same
>> problem at the same time - has to be an internal problem. The main
>> office(server site) is 192.168.1.x, and the offices are on
>> 192.168.30.x and ~40.x
>
>
> It doesn't have to be internal - for example, it could be a sluggish
> router on whatever path the two routes have in common.
>
> Things you might try
> - install some good network monitoring software
> - look at all hardware under your control and make sure you're not
> having hardware problems somewhere (firewall, border router, ...). I'm
> thinking high error counts here. I don't think this matches the pattern
> you are seeing, but it never hurts to be thorough.
> - run a low frequency ping (or udpping; need to turn the echo port on)
> from both remote systems and see if you get delays at the same time.
> - run same to another system and see if you get delays at the same time
> (unless you are 100% sure it's not a server problem).
> - capture traffic at the clients and determine if packets are being
> dropped.
> - capture traffic at both ends and measure one-way delay. (hard problem)


After running netstat I see that the ~:ipp TIME_WAIT status below
coincides with the slowdown? ipp would be a printjob, yes? Can I adjust
the tcp_fin_timeout from 60 to, say, 15 or 30?

tcp 0 0 localhost.localdomain:48751
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48750
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48763
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48762
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48760
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48767
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48766
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48765
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48764
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48755
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48754
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48752
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48759
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48758
localhost.localdomain:ipp TIME
_WAIT
tcp 0 0 localhost.localdomain:48756
localhost.localdomain:ipp TIME
_WAIT

In comp.os.linux.networking DM <dont_spam_me@reply_to_group.instead>:
> Allen McIntosh wrote:
>>
>>> they seem to be having significant keystroke delays at different times
>>> of the day(press "K" wait a second, press "I", wait...etc). those on
>>> the internal network, where the server is located, do NOT have that
>>> problem.
>>>
>>> My first reaction was that it was because of the dsl, but that can't
>>> be because two offices 75 miles from each other are having the same
>>> problem at the same time - has to be an internal problem. The main
>>> office(server site) is 192.168.1.x, and the offices are on
>>> 192.168.30.x and ~40.x
>>
>>
>> It doesn't have to be internal - for example, it could be a sluggish
>> router on whatever path the two routes have in common.
>>
>> Things you might try
>> - install some good network monitoring software
>> - look at all hardware under your control and make sure you're not
>> having hardware problems somewhere (firewall, border router, ...). I'm
>> thinking high error counts here. I don't think this matches the pattern
>> you are seeing, but it never hurts to be thorough.
>> - run a low frequency ping (or udpping; need to turn the echo port on)
>> from both remote systems and see if you get delays at the same time.
>> - run same to another system and see if you get delays at the same time
>> (unless you are 100% sure it's not a server problem).
>> - capture traffic at the clients and determine if packets are being
>> dropped.
>> - capture traffic at both ends and measure one-way delay. (hard problem)


> After running netstat I see that the ~:ipp TIME_WAIT status below
> coincides with the slowdown? ipp would be a printjob, yes? Can I adjust
> the tcp_fin_timeout from 60 to, say, 15 or 30?

You want to debug/fix the real problem, not temper with settings
one shouldn't change. What do the logs say, do you need cupsd
running at all, just stop it if not.

My first thought about your problem was improper MTU settings,
which aren't unlikely on VPN. 'ifconfig' produces some stats,
those usually tell something about the problem.

Good luck

[..]

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 14: sounds like a Windows problem, try calling
Microsoft support