Benchmarks for NICs? 10
SP99 asks: "Anyone out there read or published any good benchmark tests to compare NIC's and their performance with Linux? I hear stories of Intel and 3Com both dropping packets. Are there any authoritive sources that allow hype-free buying decisions? We all see comparisons for high profile items like CPU's, chipsets, video cards, etc...why not network cards?"
you'd have pass lots of kernel config commands... (Score:1)
In order for nic benchmarks to be accurate, would require alot of work. There are many many configureable things about each network driver, as each driver actually handles a barrage of cards. The tester would have to pass the kernel commands for each card, for each driver, in order to accurately represent each card.
Here's my experience...
I had to tweak the linux driver for an old real-tek ethernet card to work properly (basically I was lazy and didn't want to pass the kernel parameters at boot time, so I modified the driver to always be set up optimaly for the rt card), and found many many usfull comments in the driver source. I know nobody would want to read through all the net drivers just to figure out which is best, but it could be a good way to squeeze performance out of your existing network card, or get it to work period in my case. BTW real-tek nic cards work GREAT and are cheap as hell, the only time I ever had problems was using it in a 133mgz 486 class AMD, that also had a promise ultra ATA card in it. Thats why I had to tweak the driver!
Re:Well.. (Score:1)
IIRC (Score:4)
The throughput is inversely proportional to the number of NICs on the line. The protocol used in the transactions also influences throughput - TCP/IP is a military grade protocol (no matter what buzzword people say, it was a military project) so it has massive redundancy, verification and overhead. Don't forget at in the packet itself - all the layers' overheads are large, for a simple HTTP packet, there's IP, TCP and the HTTP headers which take up bandwidith but aren't counted as throughput (at least to most people).
In my experiances, DEC (tulip) and Intel (eepro100) chipsets run at about 90 Mbps on a Fast Ether and 8.5 Mbps on a simple Ether rigged on a switch linking only 2 machines (exact copies, both machines were bought at the same time from the same company) running Linux 2.2.11 with properly wired RJ45 connectors. I tried the same thing out using RTL 8092AS chipset and got a lower 80 Mbps (fast) and 8 Mbps (ether). The speed tests were run using "tar cf - | nc" and "nc -l | tar xf -" (not great but VERY fast) transfering "dd if=/dev/random bs=4k count=1M" (just for fun).
Due to those tests that I ran and counting the pile of burned out cards that I have stacked in a corner at my office, I tend to side with the 'name brand' chipsets, especially DEC (Accton cards for example) since they are cheaper than the Intel chipset and are much better than the RTL chipsets - there are 9 burned out RTL Fastethernet NICs compared to 1 Intel and 0 (ZERO) DEC.
I don't think that I helped that much and answered your question but benchmarks are though to run on NICs due to the great unknown of network deployment.
--
--
All browsers' default homepage should read: Don't Panic...
realtek (Score:1)
SMC EtherPower II (Score:2)
Other things to think about (Score:1)
CPU Utilisation? (Score:2)
Some devices, either due to poor or obsolete design practices, or badly written drivers, consume large amounts of CPU time during utilisation, making the device almost useless in a CPU intensive environment.
There's more to hardware than just the throughput.
Re:you'd have pass lots of kernel config commands. (Score:1)
Run your own benchmark, on your OS. (Score:1)
Well.. (Score:1)
ftp'ing to the 2.4 linux computer gets me on average 2000kB/s while ftp'ing into the 2.2 linux computer gets me on average 1300kB/s.
Something funny happened when nfs mounting a directory off the 2.4 linux computer onto the 2.2 one.. it froze the connection and got lots of WATCHDOG errors on the 2.4 kernel's logs and had to restart eth0. not sure if this is an NFS issue or the NIC's.