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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox