Diagnosing network slowness: server or network?

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

We have a Sun v1280 server, with users connecting via cheap Sun boxes over
the ethernet.

ftp to and from the v1280 is very slow.

In addition, some users, but not all, report very slow loading of graphics.
(They connect by XDMCP (I think that's the name) to the v1280, where they
have accounts, and run the CDE desktop.)

How do I go about making a differential diagnosis between:
* A network problem, not directly related to the v1280 itself;
* A networking problem, directly related to the v1280 (e.g., bad network
card);
* A non-networking problem with the v1280
?

TIA,

S

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

sinister wrote:
> We have a Sun v1280 server, with users connecting via cheap Sun boxes over
> the ethernet.
>
> ftp to and from the v1280 is very slow.

Does it start slowly then the conversion goes fine until
any new port is opened, or is the slowness during the
file transfer? Slowness opening a new socket will be a
DNS issue most likely broken reverse tables. Slowness
once a large file transfer has started, double check
duplex settings on all host ans switch interfaces.

> How do I go about making a differential diagnosis between:
> * A network problem, not directly related to the v1280 itself;

Do stuff between the smaller boxes to tell this.

> * A networking problem, directly related to the v1280 (e.g., bad network
> card);

Logs viewed with dmesg and logs that appear in /var/ad/messages

> * A non-networking problem with the v1280

I mentioned the likely DNS issue above.

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

Robert Redelmeier wrote:
> sinister wrote:
>
> > Is there a utility for checking network speed? Trying ftp
> > transfers is a reasonable "experiment" but kind of klunky.
>
> `ttcp`. Run it in both directions.

Second best is learning the switches on ping and
sending flurries of large packets and then seeing
your dropout rates.

Third best is spray on one end and sprayd on the other.

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

"Doug Freyburger" <dfreybur@yahoo.com> wrote in message
news:1119624257.826925.162910@g43g2000cwa.googlegroups.com...
> sinister wrote:

Thanks for your thoughtful, detailed reply.

>> We have a Sun v1280 server, with users connecting via cheap Sun boxes
>> over
>> the ethernet.
>>
>> ftp to and from the v1280 is very slow.
>
> Does it start slowly then the conversion goes fine until
> any new port is opened, or is the slowness during the
> file transfer? Slowness opening a new socket will be a
> DNS issue most likely broken reverse tables. Slowness
> once a large file transfer has started, double check
> duplex settings on all host ans switch interfaces.

Slowness during file transfer.

>> How do I go about making a differential diagnosis between:
>> * A network problem, not directly related to the v1280 itself;
>
> Do stuff between the smaller boxes to tell this.

I'll have to do more of that.

Is there a utility for checking network speed? Trying ftp transfers is a
reasonable "experiment" but kind of klunky.

Anyway...one transfer that was really slow was from another department (say
"X"). It was slow from v1280 to my PC, and between v1280 and X. But not X
and my PC.

But as far as I can tell this could still be a network thing, since it's not
all a single ethernet network; looks like there are different switches in
various places.

The curious thing is that all the cheap Suns with *really* bad problems
(i.e., graphics taking minutes to load, not just ftp slowness) show no
intervening hosts/switches/whatever when I run traceroute. Hosts that show
ftp slowness but graphics relatively unaffected show intermediate switches
according to traceroute.

>> * A networking problem, directly related to the v1280 (e.g., bad network
>> card);
>
> Logs viewed with dmesg and logs that appear in /var/ad/messages
>
>> * A non-networking problem with the v1280
>
> I mentioned the likely DNS issue above.

OK.

Thanks,

S

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

Walter Roberson wrote:
> Doug Freyburger <dfreybur@yahoo.com> wrote:
>
> :Third best is spray on one end and sprayd on the other.
>
> Ethernet wax comes in spray cans now? I thought it was strictly
> a paste that had to be rubbed in.

The wax is still only available in a paste the last
time I saw it. Now it comes in squeeze tubes that
roll up and also in standing tubes with a piston but
it's all the same paste. ;^)

The spray is like shining a flashlight into smoke.
It shows the smoke real nice but doesn't actually
solve your smoke problem.

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

In comp.dcom.lans.ethernet sinister <sinister@nospam.invalid> wrote:
> Is there a utility for checking network speed? Trying ftp
> transfers is a reasonable "experiment" but kind of klunky.

`ttcp`. Run it in both directions.

Could you have a cabling problem? Field-made cables often
have a split pair that works OK in one direction but not well
in the other. Yet still give good link lights.

-- Robert

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

In article <bqVue.295$Tk2.256@trnddc02>,
sinister <sinister@nospam.invalid> wrote:
:The curious thing is that all the cheap Suns with *really* bad problems
i.e., graphics taking minutes to load, not just ftp slowness) show no
:intervening hosts/switches/whatever when I run traceroute. Hosts that show
:ftp slowness but graphics relatively unaffected show intermediate switches
:according to traceroute.

switches don't show up in traceroute -- only layer 3 hops decrement
the TTL field so only layer 3 hops can return icmp ttl exceeded messages.

Your v1280 server is unlikely to have more than a couple of ports,
so you almost certainly have a layer 2 switch in the middle that is
not showing up.


Anyhow, your description sounds very much like duplex problems to me.
I would suggest that you should launch right in to forcing the
speed and duplex on the v1280 server and the switchport it is
connected to: instances in which forcing speed and duplex on
both ends make things -worse- are quite uncommon (but not unknown )

The test after that would be to force speed and duplex on one of
the cheap Suns you mention (and corresponding switchport).


There is no firm agreement about autonegotiation vs forced
speed and duplex. The rule of thumb that seems to be most common
is that speed and duplex should be fixed for critical infrastructure
(switches, routers, key servers), but that autonegotiation should be
used for desktops. (Opinions vary on this, though!!) The practical
idea behind this particular rule of thumb is that you can't afford
to have speed and duplex issues on the key infrastructure that does
not change very often, but that desktops tend to change too often
to make it -convenient- to lock speed and duplex for all of them...
and if something does go wrong for the desktops, it isn't going
to affect very many people.
--
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald Knuth

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

In article <1119631045.607323.62990@z14g2000cwz.googlegroups.com>,
Doug Freyburger <dfreybur@yahoo.com> wrote:
:Third best is spray on one end and sprayd on the other.

Ethernet wax comes in spray cans now? I thought it was strictly
a paste that had to be rubbed in.
--
The rule of thumb for speed is:

1. If it doesn't work then speed doesn't matter. -- Christian Bau

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

In comp.unix.admin Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca>:
> In article <bqVue.295$Tk2.256@trnddc02>,
> sinister <sinister@nospam.invalid> wrote:
> :The curious thing is that all the cheap Suns with *really* bad problems
> i.e., graphics taking minutes to load, not just ftp slowness) show no
> :intervening hosts/switches/whatever when I run traceroute. Hosts that show
> :ftp slowness but graphics relatively unaffected show intermediate switches
> :according to traceroute.

> switches don't show up in traceroute -- only layer 3 hops decrement
> the TTL field so only layer 3 hops can return icmp ttl exceeded messages.

> Your v1280 server is unlikely to have more than a couple of ports,
> so you almost certainly have a layer 2 switch in the middle that is
> not showing up.


> Anyhow, your description sounds very much like duplex problems to me.

Second that.

> I would suggest that you should launch right in to forcing the
> speed and duplex on the v1280 server and the switchport it is
> connected to: instances in which forcing speed and duplex on
> both ends make things -worse- are quite uncommon (but not unknown )

> The test after that would be to force speed and duplex on one of
> the cheap Suns you mention (and corresponding switchport).


> There is no firm agreement about autonegotiation vs forced
> speed and duplex. The rule of thumb that seems to be most common
> is that speed and duplex should be fixed for critical infrastructure
> (switches, routers, key servers), but that autonegotiation should be
> used for desktops. (Opinions vary on this, though!!) The practical

Yep, from my experience the only OS able to handle
auto-negotiation perfectly is Linux. Most distro come with
mii-tool or/and eth-tool, allowing to check/set settings on the
system (all good NICs) on Solaris ndd can do this for you. But
mii-tool allows in addition to see what the other side of the
link is advertising:

# mii-tool -v eth2
eth2: negotiated 100baseTx-FD, link ok
product info: vendor 00:aa:00, model 56 rev 0
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
^^^^^^^^^^^^ flow-control

[..]

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 224: Jan 9 16:41:27 huber su: 'su root' succeeded
for .... on /dev/pts/1

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

Michael Heiming wrote:

> Yep, from my experience the only OS able to handle
> auto-negotiation perfectly is Linux. Most distro come with
> mii-tool or/and eth-tool, allowing to check/set settings on the
> system (all good NICs) on Solaris ndd can do this for you. But
> mii-tool allows in addition to see what the other side of the
> link is advertising:
>

Where'd you find mii-tool? It doesn't seem to be part of the SuSE 9.3
distro and the first several google hits don't appear to include a download
site.

 

[Guest]

Archived from groups: comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet (More info?)

"sinister" <sinister@nospam.invalid> wrote in message
news:ysTue.3894$tA.113@trnddc06...
> We have a Sun v1280 server, with users connecting via cheap Sun boxes over
> the ethernet.
>
> ftp to and from the v1280 is very slow.
>
> In addition, some users, but not all, report very slow loading of
> graphics. (They connect by XDMCP (I think that's the name) to the v1280,
> where they have accounts, and run the CDE desktop.)
>
> How do I go about making a differential diagnosis between:
> * A network problem, not directly related to the v1280 itself;
> * A networking problem, directly related to the v1280 (e.g., bad network
> card);
> * A non-networking problem with the v1280
> ?
>
> TIA,
>
> S

Looks like it was a switched that needed readjusting.

(Why didn't the network guys working for us think of that, say, 6 weeks ago?
Got me...)