Performance issue

Hello all,

I just stuck up in an uncertain situation related to network performance...

I am trying to access one of my remote client unix machine from a distant location..

The client machine is Ultra-5_10 , with SunOS 5.5.1

The ndd result ( hme1 )shows that the machine is hooked to a 100Mbps network connection.. but the response is very poor. I mean, when I start working with a rlogin/rsh connection, the feedback is really slow.. it just hangs sometime and comes alive again...

Is there any way to measure/identify the connection in terms of bandwidth.. ?

Or anyother points to check out for a better performance...

I had glance on some of the tcp/ip stack tuning stuff.. but this machine dont have many remote connections, which force me to believe something else is wrong...

And big question is ..Am I going in the right direction ??

Here is the output of ndd check...

transceiver_inuse -- 0
link_status -- 1
link_speed -- 1
link_mode -- 1
ipg1 -- 8
ipg2 -- 4
use_int_xcvr -- 0
pace_size -- 1
adv_autoneg_cap -- 1
adv_100T4_cap -- 0
adv_100fdx_cap -- 1
adv_100hdx_cap -- 1
adv_10fdx_cap -- 1
adv_10hdx_cap -- 1
autoneg_cap -- 1
100T4_cap -- 0
100fdx_cap -- 1
100hdx_cap -- 1
10fdx_cap -- 1
10hdx_cap -- 1
lp_autoneg_cap -- 1
lp_100T4_cap -- 0
lp_100fdx_cap -- 1
lp_100hdx_cap -- 1
lp_10fdx_cap -- 1
lp_10hdx_cap -- 1
instance -- 1
lance_mode -- 1
ipg0 -- 16

Thanks in advance..

You have to look at the entire network, not just the local network. We have systems in India and when I open a telnet connection to one of them it is very slow. But my connection goes across a trans-atlantic cable to Europe, then it bounces off a satellite to a ground station in India, then it uses packet radio to get to our lan. Our lan in India is only 10 Mb, but upgrading it to 100 Mb would not help my telnet session.

Somewhere in that chain is a bandwidth bottleneck. And it's the bottleneck that determines my overall speed.

Also round-trip time is an issue, especially with that satellite bounce. Geosyncronous and geostationary satellites are in deep orbit and a human will easily notice the time it takes to bounce off of them. When I type a character, it must go to the remote system which will echo it back to me. That takes time and more bandwidth won't help that.

Perderabo is correct about the network topology situation. However, you might be able to check network throughput while copying a file or some other large bandwidth intensive task and get a quick idea of your actual throughput with netstat. I have never tried it under Solaris, but it works like a champ under FreeBSD.

netstat -I <interface> <seconds>

Where <interface> is the interface and <seconds> is the delay between updates.

Example:

FreeBSD:auswipe:/home/auswipe $ netstat -I rl0 1
            input          (rl0)           output
   packets  errs      bytes    packets  errs      bytes colls
         2     0        132          0     0          0     0
         1     0         66          1     0        178     0
         1     0         66          1     0        178     0
         1     0         66          1     0        178     0
^C
FreeBSD:auswipe:/home/auswipe $

Obviously I'm not pushing much on my local network when I ran this.

Along with Perderabo's and Auswipe's suggestion, I think you may just want to start with simple concepts to see if those pan out. Try pinging the remote system, how long does it take? If it is something like 400 ms, it's probably the WAN that is the problem and not the system itself. Do other systems at the same site have a slow response or is it just the one system? If you use traceroute, it may show you where the bottleneck in the WAN is.

Thanks a lot,

Infact, I am getting the ping echoes in an average of 30ms.

I will also look into the other possibilities suggested.

Thank you.

Just to provide another datapoint, when I ping one of our systems in India, I am getting times between 641 ms and 694 ms. I'm reasonably sure that a very large chunk of that is the satellite bounce. Your ping times pretty much eliminates the round trip time as a component of your problem.