From: TJ <systemloc@earthlink.net>
To: linux-raid@vger.kernel.org
Cc: Erik Mouw <erik@harddisk-recovery.com>
Subject: Re: Looking for the cause of poor I/O performance
Date: Fri, 3 Dec 2004 10:09:23 -0500 [thread overview]
Message-ID: <200412031009.23717.systemloc@earthlink.net> (raw)
In-Reply-To: <20041203114635.GB21302@harddisk-recovery.com>
> You won't do any better than fast ethernet when you're using a
> crossover cable. Gigabit ethernet doesn't need crossover cables for
> direct connections, it uses all four wire pairs in cat5 cable and will
> automatically figure out if there's a direct connection and do the
> right thing (all mandatory by the gigE standard, so every NIC will
> support it). If you use a fast ethernet cross cable, the NICs will
> autonegotiate to 100 MB/s full-duplex.
I did not know that auto-sensing was part of the Gigabit standard. I don't
understand why you would think that performance would be worse with a
crossover than a straight cable, though. I assure you, the link
autonegotiates to a gigabit connection. The card driver reports this, the
card's light indicator reports this, and my benchmarking of throughput has
proven it.
> The Intel gigE NICs are very good: good hardware, good driver, good
> support. Gigabit ethernet switches are becoming rather cheap: 200 EUR
> buys you an 8 port switch.
Yeah, I knew Intel made good NIC's, and I knew they were linux supported. I'm
only worried because this is the lowest end model in the line. I wonder if it
offloads work to the CPU, causing lower throughput on a busy link, while more
expensive versions handle more work on the card. Also, I have read some
traffic that the e1000 driver is better tuned for light duty connections, and
could use some improvement under a heavy workload. If you knew about any
documentation, or mailing lists on the topic of tuning this, I'd appreciate
it.
TJ Harrell
next prev parent reply other threads:[~2004-12-03 15:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-03 11:30 Looking for the cause of poor I/O performance TJ
2004-12-03 11:46 ` Erik Mouw
2004-12-03 15:09 ` TJ [this message]
2004-12-03 16:25 ` Erik Mouw
2004-12-03 16:32 ` David Greaves
2004-12-03 16:50 ` Guy
-- strict thread matches above, loose matches on Subject: below --
2004-12-02 16:38 TJ
2004-12-03 0:49 ` Mark Hahn
2004-12-03 3:54 ` Guy
2004-12-03 6:33 ` TJ
2004-12-03 7:38 ` Guy
2004-12-04 15:23 ` TJ
2004-12-04 17:59 ` Guy
2004-12-04 23:51 ` Mark Hahn
2004-12-05 1:00 ` Steven Ihde
2004-12-06 17:48 ` Steven Ihde
2004-12-06 19:29 ` Guy
2004-12-06 21:10 ` David Greaves
2004-12-06 23:02 ` Guy
2004-12-08 9:24 ` David Greaves
2004-12-08 18:31 ` Guy
2004-12-08 22:00 ` Steven Ihde
2004-12-08 22:25 ` Guy
2004-12-08 22:41 ` Guy
2004-12-09 1:40 ` Steven Ihde
2004-12-06 21:16 ` Steven Ihde
2004-12-05 2:16 ` Guy
2004-12-05 15:14 ` TJ
2004-12-06 21:39 ` Mark Hahn
2004-12-05 15:17 ` TJ
2004-12-06 21:34 ` Mark Hahn
2004-12-06 23:06 ` Guy
2004-12-03 6:51 ` TJ
2004-12-03 20:03 ` TJ
2004-12-04 22:59 ` Mark Hahn
2004-12-03 7:12 ` TJ
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=200412031009.23717.systemloc@earthlink.net \
--to=systemloc@earthlink.net \
--cc=erik@harddisk-recovery.com \
--cc=linux-raid@vger.kernel.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.