From: Samuel Flory <sflory@rackable.com>
To: Matthew Hunter <matthew@infodancer.org>
Cc: Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org
Subject: Re: 2.4.21, NFS v3, and 3com 920
Date: Tue, 22 Jul 2003 11:06:59 -0700 [thread overview]
Message-ID: <3F1D7D43.5070401@rackable.com> (raw)
In-Reply-To: <200307221319.h6MDJVgf007961@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
>On Tue, 22 Jul 2003 00:42:45 CDT, Matthew Hunter <matthew@infodancer.org> said:
>
>
>
>>Running more tests, it turns out the speed problem is isolated to
>>the one machine, and only to *receiving* data. Sending goes at
>>8 M/s to other machines from the client machine. Sending from
>>any machine to the client machine is slowed down, not just from
>>the server.
>>
>>
>
>These symptoms sound suspiciously like a 100BaseT auto-negotiation
>problem. With some combinations of gear, if one end is set to auto-negotiate
>and the other end is nailed to full/half duplex (sorry, can't remember which and
>I've not my caffiene yet), things go horribly wrong and many packets
>dissapear silently on transmission, forcing retransmit timeouts and bad
>throughput. Basically, you end up with one end thinking it's full duplex,
>the other end at half - and if the full duplex side ever sends a packet while
>the half side is sending, the packet's lost.
>
>Try nailing the devices on both ends of the cat-5 to the same thing (full or
>half). This can of course be interesting if you have an unmanaged hub that
>doesn't give you a choice...
>
>
>
>
>
You should be able to use mii-tool, or ethtool (one or both should
work) to check the state your ethernet controller thinks it is set to,
and change the settings.
[root@sflory cujo]# mii-tool -v eth0
eth0: negotiated 100baseTx-FD, link ok
product info: vendor 00:aa:00, model 51 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 flow-control
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
[root@sflory cujo]# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: puag
Wake-on: g
Link detected: yes
[root@sflory cujo]#
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory <sflory@rackable.com>
next prev parent reply other threads:[~2003-07-22 17:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-22 5:42 2.4.21, NFS v3, and 3com 920 Matthew Hunter
2003-07-22 13:19 ` Valdis.Kletnieks
2003-07-22 18:06 ` Samuel Flory [this message]
2003-07-22 18:58 ` Matthew Hunter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F1D7D43.5070401@rackable.com \
--to=sflory@rackable.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@infodancer.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.