Diagnosing network slowness: server or network? - Unix

This is a discussion on Diagnosing network slowness: server or network? - Unix ; 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 ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Diagnosing network slowness: server or network?

  1. Diagnosing network slowness: server or network?

    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



  2. Re: Diagnosing network slowness: server or network?

    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.


  3. Re: Diagnosing network slowness: server or network?


    "Doug Freyburger" wrote in message
    news:1119624257.826925.162910@g43g2000cwa.googlegr oups.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



  4. Re: Diagnosing network slowness: server or network?

    In comp.dcom.lans.ethernet 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.

    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


  5. Re: Diagnosing network slowness: server or network?

    In article ,
    sinister 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

  6. Re: Diagnosing network slowness: server or network?

    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.


  7. Re: Diagnosing network slowness: server or network?

    In article <1119631045.607323.62990@z14g2000cwz.googlegroups.c om>,
    Doug Freyburger 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

  8. Re: Diagnosing network slowness: server or network?

    Walter Roberson wrote:
    > Doug Freyburger 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.


  9. Re: Diagnosing network slowness: server or network?

    In comp.unix.admin Walter Roberson :
    > In article ,
    > sinister 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

  10. Re: Diagnosing network slowness: server or network?

    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.


  11. Re: Diagnosing network slowness: server or network?

    In comp.unix.admin James Knott :
    > 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.


    Dunno, tossed suse ages ago, after getting constantly pissed-off
    by this distro. Haven't used any other Linux distro as
    annoying, while dog slow.

    On RH and alike it comes with the net-tools package. Perhaps it
    has just been renamed by suse, who knows? Wouldn't surprise me,
    there's nothing they don't muck up.

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 187: Reformatting Page. Wait...

  12. Re: Diagnosing network slowness: server or network?

    On Sat, 25 Jun 2005 07:14:07 -0400, James Knott wrote:
    > 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.


    I can't tell for SUSE, but on Debian, it's in the net-tools package.

    You can find the original source code here:
    http://www.tazenda.demon.co.uk/phil/net-tools/

    Mirko

  13. Re: Diagnosing network slowness: server or network?


    "sinister" 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...)



+ Reply to Thread