Mixing Gigabit, Copper, and Linux 249
iampgray writes: "With copper-based gigabit cards selling for less than $36 these days, what kind of performance can you expect -- especially in the often-overlooked Linux market? We sought out to test exactly what you could expect from copper-based gigabit solutoins for the desktop interface through the cluster-targeted products. Name brands and off-brands were put through the wringer. How'd they fare? Interesting results to say the least."
I was able to get 800MB/sec on a Linux 2.4 kernel (Score:1, Informative)
Huh. (Score:2, Interesting)
How much more expensive is the optical stuff for GigE? I'm mostly using optical audio connections from my home sterio, and that's not to much money
Re:Huh. (Score:2, Informative)
Gigabit, not GigaByte. Gigabit = 1000000000 bits. GigaByte = 8000000000 bits. A 1 GBps connection is 8 times faster than a 1 Gbps connection.
Heh. (Score:2)
Re:Huh. (Score:4, Informative)
I use optical runs for my audo as well, but those are all under a meter, for the most part, and around $30 or so a piece. Not too much money for the purpose, but I dont' think I'd enjoy paying for a 50 meter run. Never mind the cost of devices with optical interfaces.
That said, I guess the only reason I'd consider GB copper is that it's no more expensive than 100 base-T...
$30 for 1m!? (Score:2)
Re:$30 for 1m!? (Score:1)
You are paying too much for your cable (Score:2)
IF Eithernet fibre was as expensive as you suggest, the university I work at would be bankrupt. Just last week I laid about 50 30-metre patch cables in a closet. This is not to mention the thousands already in place and the millions of metres of fibre that connects the buildings together.
Re:You are paying too much for your cable (Score:1)
Re:Huh. (Score:5, Interesting)
Yes. Some memory parts are 333 Mhz and are 4 bytes parallel and instructions/s (as opposed to the clock rate) is over 1 GIP I think. So a PC can just about knock out a gigabyte/s if it has to, but it hasn't got much time to think about anything.
But this article is talking about gigaBITs/s. That's 8x slower. So that too.
Re:Huh. (Score:4, Informative)
Re:Huh. (Score:3, Insightful)
A 32-bit 33 MHz PCI bus can support one (1) gigabit ethernet card at full capacity (card's bandwidth is about 100 Mbytes/sec, PCI 32/33 is 133 Mbytes/sec).
If you want to stick multiple cards in (e.g. for a small hypercube-style cluster), buy motherboards that support 64/33 or 64/66 (I was drooling over the dual-processor 64-bit-PCI AMD boards a little while back).
Gigabit ethernet over copper has the advantage of running over your existing cabling (i.e. cat-5 is fine). This avoids having to muck about with fiber, as fiber is a PITA to maintain yourself (getting optically perfect connections for the fiber jacks is picky).
The way gigabit ethernet is encoded on cat-5 cable is both sneaky and elegant.
Re:Huh. (Score:2, Informative)
Actually, the siecor unicam series work really, really well. They use a index of refraction matching gel inside the factory polished terminators. All you have to do is cut'n'crimp. They work great. I haven't ever had to do any splicing though - but, given how well the siecor stuff works, I can't see it being a remarkable problem.
Re:Huh. (Score:2, Insightful)
Almost. 133MBytes/sec = 1064Mbit/sec. This means that it could only in theory keep up, if all bandwidth on the PCI bus was available for data. But, this number includes the overhead of setting up transfers and arbiting for devices that want to transfer, and these operations are fairly expensive.
Also, the PCI device needs to obtain descriptors etc. (which indicate where to put the Ethernet packets in RAM) over the same bus, costing more valueable cycles.
If you did have only the one device on the PCI bus (which is very unlikely), with a good chipset, you'd probably get over 100MB/sec, but not much more. So you'd never be able to actually get full Gb Ethernet. (as the test results show, things are MUCH worse then this, but this is probably caused by multiple devices on the PCI bus).
Talking about chipsets, a long time ago we had a board with an OPTi chipset. They ran out of silicon when designing the chip, so they couldn't implement the Bus Master FIFO, so they decided to just abort every BM cycle after each 32 bit transfer, yielding a max transfer rate of 4MB/sec!! For weeks, I couldn't figure why my network driver wouldn't send packets faster than 30 Mbit/sec, until my boss flew to California (where OPTi was located) to find out what we where doing wrong.
Back to the tests: for some reason they failed to mention the chipsets used on the motherboards which really is VERY important if you want to use a gigabit Ethernet card in a 32/33 PCI system. The fact that the Dell has 5 PCI slots probably means that it has an integrated PCI-PCI bus (not many chipsets support 5 PCI slots, unless one or more of them do not support Bus Mastering), which would certainly not improve things.
I think this is important to mention, because most systems today, at least desktops, will only have 32/33 PCI, and as the test results show, with a presumably shitty chipset, you only get marginally better performance than 100Mb Ethernet...
copper vs fibre... (Score:1)
The problem with fiber vs copper isn't really the cost of the medium, it is the cost of laying the infrastructure. If I remember correctly, the cost of the cable is about 1/10 of the total cost.
Part of the reason gig-e has become so cheap so quickly is that it has been able to ride the ethernet adoption curve to make the MACs and copper transcievers cheap because of the huge volumes. These volumes will never be reached by fiber.
-tpg
Re:copper vs fibre... (Score:2)
Sheesh - a TDMA for fiber can tell you not only the quality of the cable and terminations, but also the distance to any faults!
(Believe me, I've got a OmniScanner for copper and I'm itching for Fiber - i just can't justify the cost yet. Troubleshooting cable run problems is really a breeze! And no guessing either. If the "Joes" you got installing fiber don't give you full certification results, you've not done your job in setting the specs for the job. And if your cable is getting damaged after install, either the cable didn't get installed right (protected runs etc) or you've got very careless people running around where they shouldn't.
Fiber is more difficult, but that's really because it hasn't reached critical mass. Once it starts getting installed in higher quantities, we'll see easy termination kits (there are some already).
Cheers!
I didn't even notice 1000bT was so cheap... (Score:2, Insightful)
Nope... apparently Pricewatch.com has D-Link 8-port 10/100/1000baseT auto-detect switches listed for under $150! (I've been most happy with my D-Link DI-804 Router/firewall/switch for $79.)
Is this the normal "cheaper as tech gets more widespread and easier to manufacture," and do you think maybe Apple making gigabit ethernet a standard feature had something to do with it?
Re:I didn't even notice 1000bT was so cheap... (Score:1)
Switches aren't cheap. (Score:5, Informative)
These are for 8x100-base-T with a gigabit uplink. I researched this a while ago, when speccing out my dream network
The cheapest full-gigabit switch D-link sells is about $1500.
Re:Switches aren't cheap. (Score:2)
As long as it is a small network and no machine goes off line it should be ok.
Perhaps an expert knows if you could have two virtual IP's per card, a simple "Y" splitter plus two cross-over cables running into each machine via the splitter?? That might be a cheaper ring configuration.
Cheers,
-B
Re:Switches aren't cheap. (Score:2)
That would give real below average performance, even if you did get it to work. IT would be a nightmare getting all the routing setup properly so the computers would pass packets around the ring correctly. And once you got it working, speed would suck. Every packet would have to be evaluated in software and then routed to the next interface if necessary. This would be slow as hell, neurtalising the speed advantage.
Perhaps an expert knows if you could have two virtual IP's per card, a simple "Y" splitter plus two cross-over cables running into each machine via the splitter??
That would work like not at all.
Re:Switches aren't cheap. (Score:1)
Re:I didn't even notice 1000bT was so cheap... (Score:1)
FP.
Re:I didn't even notice 1000bT was so cheap... (Score:2)
Re:I didn't even notice 1000bT was so cheap... (Score:5, Informative)
D-Link's site is nearly impossible to navigate (maybe it requires JavaScript, which I've shut off), but the Pricewatch description of the DES-1009G indicates that Gigabit Ethernet is only available on one port as an uplink connection; the rest of the switch is your run-of-the-mill 10/100 job. The DGS-1008T is D-Link's 8-port unmanaged 10/100/1000 switch; the cheapest entry on Pricewatch for that is $595.
BTW, I have the entire site downloaded. Maybe I'm insane to even think about mirroring a /.'ed article on my home cable-modem link, but here it is [dyndns.org]. I've converted all the charts to PNG so they'll load slightly faster, and I got rid of most of the godawful "super-31337" yellow-on-black text to improve readability. You can also choose this link [dyndns.org] to download the entire page (images and all) in one shot.
Re:I didn't even notice 1000bT was so cheap... (Score:2)
Re:I didn't even notice 1000bT was so cheap... (Score:1)
Or use the uplink to connect to a backbone network. That's really what the uplinks are there for.
Hoboy. (Score:4, Funny)
Not terribly well against the
Interesting results to say the least.
Lessee, a story about increasing bandwidth on a server
Soko
Re:Hoboy. (Score:2)
Has anybody read the article yet? (Score:3)
Obligatory Mac Plug (Score:4, Informative)
Re:Obligatory Mac Plug (Score:3, Insightful)
Note: When connecting a Power Mac G4 computer directly to another computer without using an Ethernet hub, a crossover cable is not required; circuits in the PHY detect the type of connection and switch the signal configuration as required.
Re:Obligatory Mac Plug (Score:2)
Re:Obligatory Mac Plug (Score:2)
So what? (Score:2)
So does that mean my $99 Gigabit Ethernet Card is at least as special as your $3000 Mac?
Re:Obligatory Mac Plug (Score:2)
How about a price/performance comparison then? (Score:2)
Clusters (Score:3, Informative)
Intel NIC's (Score:2)
I've had really good experiences with Intel NIC's, and in fact have two Pro 100/S Server Adapters and two Pro/1000 T Server Adapters (the forefather to the newer 'server' class models) for use in my systems-- Intel's driver support is absolutely amazing, and incredibly stable/friendly. The fact that they offer up alternate platform drivers is just another bonus.
Gigabit and Linux (Score:5, Informative)
I set up optical gigabit for some NAS type things at work, and out of the box, GBit performed maybe 30% better than 100 Mbit. We are talking about 110Mbit peaks, compared to 80Mbit peaks with 100Mbit switched.
Setting the MTU to 6144 (max that I could set it to with the ns83820.o) I started to get peaks around 300Mbit/sec.
I tried recompiling the module for higher limits, since in the source it has:
#define RX_BUF_SIZE 6144
But if I put in 8192, or 9000 like I wanted it to be, it would crask or lock up.
Anyway, it's not trivial to get good performance out of GBit, and definitely don't expect anywhere near 10X gain.
30% vs 30% (Score:1)
Re:Gigabit and Linux (Score:2)
Re:Gigabit and Linux (Score:1)
b) The only card they got 900Mbps out of cost $570, the lower cost ones got no where near that, especially with 1500 MTUs
Also, I forgot to mention, even if your switch can handle jumbo frames, if you use UDP for anything, trying to talk to a 1500MTU host from a jumbo frames host in UDP won't work (i.e. NFS).
switches? (Score:1)
Re:switches? (Score:2)
Of course in a perfect world, I'd agree that 8 port gigabit switches being $200 or less would be about near perfect, especially if higher port counts weren't unrealistically high.
Cheap NICs, costly switches (Score:5, Informative)
Re:Cheap NICs, costly switches (Score:1)
Funny, this gets modded up as Informative, while my earlier post listing inexpensive 8-port gigabit switches [slashdot.org] languishes unmoderated.
Slashdot moderation, yet another mystery of the universe. Even after reading the guidelines twice, I can't figure out how other people manage to interpret them [slashdot.org] the way they do.
Re:Cheap NICs, costly switches (Score:3, Funny)
The flogging will happen later, when my karma gets updated.
Re:Cheap NICs, costly switches (Score:1)
Currently, all Gigabit Ethernet equipment is based on the full-duplex mode of operation. To date, none of the vendors have plans to develop equipment based on half-duplex Gigabit Ethernet operation.
Which would explain why there are no Gigabit Ethernet hubs available (hubs aka repeaters are half-duplex devices). Carrier extension and frame bursting are not needed in full-duplex mode, which would make the design of full-duplex devices simpler, I guess.
On a side note, in the article, they used Ethernet Jumbo Frames which were not part of the official IEEE standard as of the writing of the book.
Re:Cheap NICs, costly switches (Score:2)
gig-e hubs (Score:1)
-tpg
Re:Cheap NICs, costly switches (Score:2)
Re:Cheap NICs, costly switches (Score:3, Interesting)
Re:Cheap NICs, costly switches (Score:2)
Consider looking for such a thing.
I have Paul Gray for a professor (Score:2)
A 64 bit PCI card was getting significantly higher throughput. I don't remember the exact numbers, but it was much closer to 1000Mbps (maybe 800?).
My experiences with DGE500T (Score:5, Informative)
I got about 32 MByte/s one-way with `ttcp` [UDP] between a 1.2GHz K7 and 2*500 Celeron (BP-6) through a plain crossover cable.
Not bad, but only 25% of wirespeed (125 MByte/sec). I figured the main limit was the PCI bus, which would only burst at 133 MByte/s, and I strongly suspected that the bursts were too short to achieve anything like this speed. I have yet to play with the PCI latency timer.
One thing for sure -- it isn't the CPU speed or Linux network stacks. The K7 will run both ends of ttcp through the localhost loopback at 570 MByte/s, and the BP6 around 200 MB/s.
Re:My experiences with DGE500T (Score:2)
Re:My experiences with DGE500T (Score:2)
Re:My experiences with DGE500T (Score:1)
Re:My experiences with DGE500T (Score:4, Interesting)
The second type of latency is the amount of time it takes a target to return a second word in a Burst transaction. This is 8 33MHz clocks, according to the PCI 2.2 spec.
The setting you are playing with in BIOS is probably the first latency... which is basically a setting in the PCI master, deciding how long to wait for data from a target before deciding to change the transaction to a delayed read. A delayed read basically frees the bus, and the master will check back with the peripheral at a later time to see if it has the data ready yet or not.
delayed reads slow down access to that peripheral, because no other transaction is allowed to take place with that peripheral until that delayed read is finished.
Older PCI cards didn't have the 16 clock limit on returning the first word of data, and they usually took longer. On new systems that try to be pci 2.2 compliant, to prevent a bunch of delayed reads from taking place, you have the option of increasing the latency timer in bios, so that it won't time out exactly on the 16 clock boundry, thereby speeding up access to that peripheral, at the cost of hogging the bus.
So anyway, adjusting the latency timer isn't likely to have an effect on newer peripherals... unless you make it too short, causing a bunch of delayed reads, and then your system will slow down.
--Scott
Re:My experiences with DGE500T (Score:2, Interesting)
But I thought there was a register (oddly named latency) that governed how long a busmaster could burst when someone else wanted the bus.
Re:My experiences with DGE500T (Score:2, Interesting)
Another evaluation of GigE performance (Score:4, Informative)
AGP NICs (Score:2, Interesting)
Re:AGP NICs (Score:1)
Re:AGP NICs (Score:1)
But what the hell do I know.
Re:AGP NICs (Score:2)
Note that PCI too can access memory "directly" (ie it can initiate a transfer) and that PCI chipsets used in Alpha's (21174 and up) and Sun have IO-MMU's. However, there is no requirement for PCI host bridges to be able to translate memory accesses.
IO-MMU's are useful on 64bit machines. Without them data held outside of the 4GB of adddress space that PCI can reference must be first copied into address space accessible to the PCI card (bounce buffering) - which is bad for performance. With an IO-MMU you can map the PCI address space to wherever you want in system address space.
Good IO-MMUs (eg the DEC 21x7x) can map very specific ranges of bus addresses to multiple ranges of system address space (ie hardware scatter gather).
Re:AGP NICs (Score:1)
Oh for the love of Pete! (Score:1)
Re:Oh for the love of Pete! (Score:1)
possible? (Score:1)
The gigabit network would be used exclusively for transferring files (> 1 GB uncompressed video) between machines. Would it just be easier (and cheaper) to do some hard drive swappage when needed?
In your case, go with removable drives... (Score:2)
Obviously you are working on a bit smaller of a scale, but you would still have to consider the cost of a GBit switch and I don't think I've seen one any cheaper than $500 (but granted, I haven't looked hard in 3-4 months). In your sitiuation, just based on my recent experiences, I'd most definitely go with removable drives.
Stuff about Gbit.... (Score:4, Interesting)
With 10 mbit cards, having the card generate an interrupt with ever incoming frame wasn't too bad. And on 100-mbit, it's still managable - but at a full gigabit, it really, really starts to bog down the machine. Some cards get around that by using interrupt coalescing, where they buffer up a few frames before they trigger an interrupt. That has a drawback, though: It increases latency. The trade-off has to be at some point, and not choosing the RIGHT point can affect either throughput or latency.
Furthermore, to get the full benefit out of your card, you generally need to enable jumbo-frames on both the card and the switch - and of course, your switch has to support that feature.
To make matters even worse, you can't always pump out (or receive) a full gigabit in any other than testing situations. Say you're receiving a large incoming file via FTP, NFS, or the protocol of your choice. Can your machine *really* write data to the disk at over 100 megabytes per second? And if it can, can it really handle both receiving a gigabit from the card, processing it, and writing the gigabit out to the disk? Unless you've got a very large amount of money in the machine, it probably won't.
steve
Re:Stuff about Gbit.... (Score:2)
Why not trigger the interrupt immediately, but continue to buffer frames and let the CPU grab all the frames in one go when it gets around to servicing the interrupt?
Actually, with a sophisticated card, driver, and OS, the range of systems which could pull in a full gigabit/sec would be vastly increased. It requires some careful thought and programming.
I sat down and sketched out a sample of how things might go, and realized I was missing some important details. On detail being the fact that it takes time to copy the data from the card to memory, and the CPU can be doing other things in that time. So, it requires more than 10 minutes thought, but I'm sure given a day or two, and access to relevant documentation about how various bits work, I could sketch out a driver design that made near optimal use of the available hardware, and wouldn't be that hard to implement in hardware either.
Re:Interrupt coalescing and latency... (Score:2)
IMHO, the 'intelligent descision' should just fall out of how it's all designed instead of being an explicit part of the low level design.
yet more Excel graphs (Score:1)
Too bad the open-source community doesn't have a better alternative. I've tried Grace...the learning curve was a little steep. Guppi is not ready, not is KChart. The best I've found so far is Octave, a open-source Matlab clone [octave.org]. That's because it provides an interface to GNU plot and Matlab is very familiar to me.
Re:yet more Excel graphs (Score:2)
Why copper? (Score:2)
Gigabit optical network cards a only a little
over a 100$ now, are full duplex and faster
than copper in most cases. We've just installed
4 Dual Athlon 2000MP linux boxes, with gigabit
optical cards, pretty damn fast as you can
imagine.
A real measurement problem (Score:3, Funny)
Wow. That makes any analysis tough, when performance measures fail to satisfy the Reflexive Property!
Brian
So how much fits into Gigabit/s? (Score:2)
The much nicer interface would be to have a living room box join my ethernet LAN. The box would just receive uncompressed audio and video from the computer over gig ethernet. That way, all the decompressing would be done by the fancy CPU in my bedroom, and the box would not become obsolete when new/more CPU-intensive codecs came out. (Because the alternative is, of course, to have the box do the decompression, but I don't like that.) Somebody please make one of these (or explain why it would be a bad idea).
Re:So how much fits into Gigabit/s? (Score:2)
Great uses for gigabit Ethernet on Linux (Score:5, Interesting)
For those of you who don't know how this works, here's a bit of a primer: basically, you set the port on your big data center grade switch to "trunk" and then you enable 802.1q on your Linux box. Then you don't just have one Ethernet interface with one address --- you have up to 4096 virtual ones, each on its own VLAN and each with an IP address that's valid on that VLAN. So you'd have eth0.1, eth0.2, eth0.3, etc... each talking to the machines on that VLAN.
Once you've got that running, you can do all sorts of neat stuff, including:
As you can see, it's limited only by your imagination. And with that much stuff potentially running through the box, you're going to need that 1 Gbps of speed. Happy hacking!
Re:Great uses for gigabit Ethernet on Linux (Score:2)
NetPipe numbers are wrong, megabits in 1024*1024 (Score:2)
It gives you a NetPIPE.out. According to the man page, they contain: "time to transfer the block, bits per second, bits in block, bytes in block, and variance."
First of all, the manpage is wrong because the second column gives a number much closer to megabits per second, and after numerical verification, I found that it's giving the value of 1024*1024 bits per second and not 1000*1000 bits per second.
In NIC-talk, when we say gigabit, we mean 1000,000,000 bits, not 1000*1024*1024 bits.
So when benchmarking your gigabit network card with netpipe, please remember that you're looking at speed results "1024*1024"-megabits, so your NIC is really only 953.6 megabits, which immediately gives a much better insight into the speed achieved by the Syskonnect card.
Any experience with 2 cards in one cheap system? (Score:2)
Pretend I have 3 cheap Athlon based systems in one building. Assume one is acting as a server, and the other two are clients that aren't talking to each other. Because these are the cheaper cards, I only expect 300Mbps when one client is active. What happens when both clients are active?
Ideally, throughput would be no worse than 150Mbps/per card. I suspect it would be much worse.
If multiple cards did work well, then you could buy 6 cards to directly connect 3 machines. Much cheaper than 3 cards and a GigE switch.
I think I'll have to wait until even cheap machines have 64bit/66Mhz PCI busses. I know I'll have to wait until I get all my machines into one building.
Intel e1000 adapter (Score:2)
There must be something wrong with the graphs for the e1000 packet size vs. throughput plot [uni.edu], I believe the axis are reversed.-
Also Intel acknowledges that their e1000 adapter have driver issues under linux. This text is from: ftp://aiedownload.intel.com/df-support/2897/ENG/re adme.txt [intel.com]
Known Issues
============
Driver Hangs Under Heavy Traffic Loads
Intel is aware that previously released e1000 drivers may hang under very
specific types of heavy traffic loads. This version includes a workaround
that resets the adapter automatically if a hang condition is detected. This
workaround ensures network traffic flow is not affected when a hang occurs.
This is for the driver verion 4.1.7, released 3/23/2002 (ie. quite new). Older versions had even bigger problems. This might explain why the Intel adapter does so bad in this test. I wish that Intel gets a clue and releases all card specs and GPLs the existing driver so that a true (stable) open source driver could be written and included in the linux kernel. I think the hardware is OK, but the drivers sucks.
Build your own Gigabit Switch! Fun Project? (Score:2)
So how about filling up a cheap PC with cheap NICs and using it as a switch?
Granted as others have said, the PCI bus is a limiting factor. But it will certainly blow away any 100mbit switch.
Another possibility is to put two Gigabit NICs in every machine, and run a daisy chain or even a ring type network.
Sounds like a fun project!
Don't get a cheezy 1000T card (read on) (Score:2)
I went on reading about it on the net, on sites like www.3wire.com for example, and to make a long story short, Fiber optic yeilds the best results (obviously) but are way to expensive. Next are some 1000T copper cards that are almost doing the job, but then again, after getting 5 different cards, I can tell you right away that you can have a BIG difference from a board to another.
The best card I've got so far performance-wise are the Intel Pro 1000T-based adapters, with no optimization card to card running netcps, I'd get twice as much speed out than with the Dlink counterpart (DGE500T). They are a bit more expensive, but if you want more than 3x increase over 100Mbits, you need something a tad more expensive.
The other thing is you see card with 70Megs/second bandwidth tests on some websites, with jumbo packets turned on. You need a jumbo-frame capable switch (read: Expensive) to be able to turn that on. The cheapest gigabit switch I've found that could take an aweful lot of load without costing me an arm was the Netgear GS508T, but if you are used to managed switch, that one isn't.
Also you might be tempted to get a Gigabit card as upling with let's say 8 ports @ 100Mbits, that way you won't waste bandwidth to the server and the 8 of them can crunch it. Well good idea on paper but don't get the Dlink DES-1009G, I had to return 2 of them, and the firmware on that thing truely SUCKS. You can't just leave it there and forget it, you need to cycle the power sometimes so it can "read properly" on the ports wether 100 or 10 or half or full duplex. It's miserable and poor performing. It's cheap though
For the Intel pro cards, I got both the workstation and server ones, server being 64bits PCI.
There's one thing you want to consider, if you use Gigabit ethernet, you need also to be able to feed it, 50megs/second on the board requires a drive being able to deliver 50 megs a second to the card, and requires a PCI bus able to take the load as well (remember, it's 50megs x 2 bandwidth on the bus that on pci32/33mhz saturates at 128 but in real world 100).
Re:Text of Article (second section) (Score:2, Informative)
D-Link DGE-500T was the first of the gigabit cards tested. This card is based on SMC's dp83820 chipset and is designed for a 32bit bus. The chipset in this card turned out performance nearly identical to the two Ark cards and the GigaNIX cards tested in our test suite, since all utilize the dp83820 chipset from SMC. The Linux driver used was the ns83820 as included in the 2.4.17 kernel. Latency on both platforms was
Peak throughput while operated in a 32bit bus was 192.21 Mbps. This was achieved in the Dell systems. The Athlon systems only obtained a peak of 172.21 Mbps when these cards were inserted into the 32-bit bus. Both systems show a slight drop in throughput but eventually level out. Peak throughput while operated in a 64bit bus running at 33Mhz was 315.96 Mbps.
When the bus was jumpered to autoselect 66/33Mhz, the performance increase was negligible. Peak throughput was 316.40 Mbps. Comparing the plots of the 66Mhz and 33Mhz run reveals that they are essentially identical.
For complete testing results, click here.
Price: $45
The cost per Mbps is as follows:
32bit 33Mhz: $45
64bit 33Mhz: $45 / 315.96 = $.14
64bit 66Mhz: $45 / 316.40 = $.14
Ark Soho-GA2500T
The Ark Soho-GA2500T is also a 32-bit PCI card design. Like the D-Link DGE-500T and the Asante GigaNIX cards, this card is based on the SMC dp83820 chipset. With that in mind the performance was estimated to be close to the D-Link DGE500T. The driver used was the generic ns83820 included the 2.4.17 kernel. The latency for both test systems was
The peak throughput achieved while in a 32bit 33Mhz bus was in the Dell system: 192.62 Mbps. While the Athlon system in the same bus setup only reached 172.19 Mbps. As before, there is a performance drop at the 1Kb and 5-10Kb packet sizes.
Peak throughput while operated in a 64bit bus running at 33Mhz was 610.83 Mbps and 609.98 Mbps when running at 66Mhz respectively. As with the Soho-GA2000T, there is no noticeable difference between a 33Mhz and a 66Mhz bus.
For complete testing results, click here.
Price: $44
The cost per Mbps is as follows:
32bit 33Mhz: $44 / ((192.62+172.19) / 2) = $.24
64bit 33Mhz: $44 / 610.83 = $.07
64bit 66Mhz: $44 / 609.98 = $.07
Ark Soho-GA2000T
Our transition into cards designed for a 64-bit PCI bus began with the Ark Soho-GA2000T. Like it's 32-bit counterpart, this card was designed around the ns83820 chipset, which will allow us to examine the performance benefits, if any, in moving from a 32-bit As
Designed to run in a 64bit 66Mhz slot, this card is backwards compatible to 32bit and 33Mhz slots. This card is based off of SMC's dp83820 chipset so performance was expected to be similar to the DGE500T and the Soho-GA2500T. The driver used was the generic ns83820 included in the 2.4.17 kernel. Latency was
Peak throughput for a 32bit 33Mhz slot was 189.93 Mbps in the Dell system. The Athlons were only able to reach 172.26 Mbps.
Peak throughput for 64bit 33Mhz was 665.06 Mbps with an MTU of 6000. Peak throughput while running at 66Mhz was 640.60 Mbps. With the exception of the 6000MTU tests, there is no noticeable difference between bus speeds of 33 and 66Mhz.
For complete testing results, click here.
Price: $69
The cost per Mbps is as follows:
32bit 33Mhz: $69 / ((172.26+189.93)/2) = $.38
64bit 33Mhz: $69 / 665.06 = $.10
64bit 66Mhz: $69 / 640.60 = $.11
Re:Text of Article (third section) (Score:1, Informative)
The second 64bit card tested was Asante's Giganix. This card is designed for a 64bit bus but, is backwards compatible to 32bit and 33Mhz configurations. Giganix is based off of the dp83821 chipset. The driver supplied by Asante was unable to compile due a bug in the code. In order to get the card to work the generic ns83820 driver was used again. Performance was expected to be similar to the GA2000T. Latency was
Peak throughput for a 32bit 33Mhz configuration was 238.75 Mbps in the Dell systems, with a peak of 172.19 in the Athlons. When comparing to the GA2000T, the Athlon results stay about the same whereas the Dell systems increase by 50Mbps.
Peak throughput for 64bit 33Mhz 641.02 Mbps with an MTU of 6000. When running at 66Mhz, the peak is 651.51 Mbps with the MTU at 6000.
An interesting spike in throughput on the 64bit 66Mhz tests was when the MTU was set to 3000. Aside from the 40Mbps difference between the two bus speeds, the plots look very similar. The main difference is the spike at 8KB packets.
For complete testing results, click here.
The cost per Mbps is as follows:
32bit 33Mhz: $138 / ((238.75+172.19) / 2) = $.67
64bit 33Mhz: $138 / 641.02 = $.22
64bit 66Mhz: $138 / 651.51 = $.21
Syskonnect SK9821:
The first of the Syskonnect cards tested was the SK9821. This card is designed for a 64bit bus. The SK9821's are backwards compatible to 32bit and 33Mhz configurations. The driver used was sk98lin from the kernel source. Latency was
Of all cards tested, the Syskonnect SK9821 gave the most consistent throughput over all packet sizes, and was far-and-away the overall performance leader.
In the server-class testing environment, peak throughput in our 64 bit 33Mhz setup was 782.27Mbps with the MTU set to 9000. The peak for 66Mhz tops off at roughly 940Mbps with jumbo frame MTU sizes of 6000 and 9000.
Peak throughput on 32bit 33Mhz was 365.27 Mbps on the Dells. After the peak, is reached there is a noticeable drop in throughput as it levels off to the 330Mbps range.
For complete testing results, click here.
Price: $570
The cost per Mbps is as follows:
32bit 33Mhz: $570 / ((365.27+163.97) / 2) = $2.15
64bit 33Mhz: $570 / 782.27 = $.73
64bit 66Mhz: $570 / 938.97 = $.61
Syskonnect SK9D21:
The second card tested from Syskonnect was the SK9D21. The SK9D21 is aimed at the desktop/workstation market. While support for this card under Windows environments appears to be solid, there were too many technical issues. The testing environment's mix of kernel, motherboard, Athlon chipset, and Syskonnect drivers made for too many components to successfully debug the problems with this card thoroughly. This card is designed for a 64bit bus the card is backwards compatible with 32bit and 33Mhz configurations. While an exhaustive analysis of the cards was unavailable, it should be noted that the latency was successfully determined at
Our difficulties with this card were limited to the 64-bit bus. Our tests were successful in analyzing the performance in both the QLITech Linux Computers Athlon-based systems and the Pentium-based systems in 32-bit busses.
When drivers issues for this card are resolved, performance evaluations in this section will be amended.
Peak throughput in the Dell system was 377.53 Mbps. As with the SK9821, there is a drop off after the peak is reached.
For complete testing results, click here.
Price: $228
The cost per Mbps is as follows:
32bit 33Mhz: $228 / 377.53 = $.60
3Com 3c996BT:
The next card in the test suite was the 3Com's 3c996BT. This card is designed as a 64bit 133Mhz card, but is backwards compatible to 32 bit, 33 and 66Mhz configurations. The driver used was the bcm5700, version 2.0.28, as supplied by 3Com. Latency was
The peak throughput achieved in this card while in a 32bit 33Mhz slot was 436.23 Mbps in the Dell systems. In the Athlon system, the same bus configuration only reached 184.02 Mbps.
Peak throughput while running in a 64bit 33Mhz slot was 884.09 Mbps this was with an MTU of 4000. While running at 66Mhz, the peak was only 546.16 Mbps with an MTU of 6000. These plots are all relatively smooth when compared to the other plots for this card.
Performance in a 66Mhz slot is actually lower for all MTU sizes as compared to a 33Mhz slot.
For complete testing results, click here.
Price: $138
The cost per Mbps is as follows:
32bit 33Mhz: $138 / ((436.23+184.02) / 2) = $.44
64bit 33Mhz: $138 / (884.09) = $.16
64bit 66Mhz: $138 / (546.16) = $.25
Intel Pro 1000/XT:
The final 64bit card tested was Intel's E1000 XT. As with the 3c996BT this card is designed for future PCI-X bus speeds running at 133Mhz. It is compatible with a variety of configurations running at 33 and 66Mhz as well as 32bit. The card uses Intel's e1000 module, version 4.1.7. Latency in the Athlon systems was
Peak throughput achieved was 743.14 Mbps while running in a 64-bit 66Mhz slot with the MTU set to 9000. Performance in a 32-bit configuration turned out the lowest throughput for all cards tested coupled with the most erratic throughput. During the throughput tests, the card would drop 100% of packets for extended lengths of time. Initial testing in the 64-bit setup showed performance similar to the Giganix card with regards to a 64-bit bus. Once the MTU was set to 9000 performance became very erratic, stagnated several times, then stabilized once the packet size reached an upper threshold peak. Note that the drop in performance was not associated with the (expected) phenomena of packet reassembly when the TCP packet size exceeds the MTU.
As testing continued the the 66Mhz phase things only got worse. Once the MTU exceeded 3000, performance was no longer predictable. During the 4000 MTU tests, the throughput plummeted to around
For visual clarity of this phenomena, see the ''Complete Test Results'' link for the Intel Pro 1000/XT below.
For complete testing results, click here.
Price: $169
The cost per Mbps is as follows:
32bit 33Mhz: $169 / 142.02 = $1.18
64bit 33Mhz: $169 / 624.41 = $.27
64bit 66Mhz: $169 / 743.14 = $.22
Re:Text of Article (fourth section) (Score:2, Informative)
In this section, we compare performance differences between cards in like environments , provide some general performance observations, and examine the cost per megabit as determined by the operating environment.
Head-to-head throughput results
While the results obtained in this study clearly show that peak performance is not a complete indicator of peak performance, in this section we examine the peak performance results amongst all cards under common environments.
32-bit, 33MHz PCI Bus, 1500 MTU
64-bit, 33MHz PCI Bus, 1500 MTU
64-bit, 66MHz PCI Bus, 1500 MTU
64-bit, 33MHz PCI Bus, 3000 MTU
64-bit, 66MHz PCI bus, 3000 MTU
64-bit, 33MHz PCI bus, 4000 MTU
64-bit, 66MHz PCI bus, 4000 MTU
64-bit, 33MHz PCI bus, 6000 MTU
64-bit, 66MHz PCI bus, 6000 MTU
64-bit, 33MHz PCI bus, 9000 MTU (Note: Drivers for the dp83820 chipset were limited to around 6000 MTU)
64-bit, 66MHz PCI bus, 9000 MTU (Note: Drivers for the dp83820 chipset were limited to around 6000 MTU)
General Observations
Of the eight cards tested, the clear performance champion was the SK9821 with regard to throughput and consistency. The 3Com 3c996BT has a modest price tag and respectable performance for the entry-level server configuration. If price per megabit is the main concern, the Ark Soho-GA-2500T has the lowest cost per Mbps, making it a viable solution for entry-level systems requiring higher throughput than fast ethernet.
The D-Link DGE500T and the Soho-GA2500T show nearly identical peaks, which is to be expected since the drivers and the chipsets were the same.
The 3Com 3C996BT has results when compared to the 64-bit 33MHz results were surprising inasmuch as these cards showed better performance at 33MHz bus than at the higher 66MHz bus.
Of all of the cards tested, the Intel E1000 TX proved to be comparable to the comparable to the Asante GigaNIX card in peak performance, but the erratic overall performance proved too much to overcome.
In referring to the Complete Test Results sections for the 3C996BT and the SK9821 cards, one sees a very consistent and smooth transition to the peak throughput of the cards over the complete range of packet sizes.
Some general comparisons that can be derived from the above results include the notion of ''cost per peak megabit. Depending upon the environment that the network device is to be installed, the cost per peak megabit varies greatly. For example, if one would wish to upgrade their P-III-based desktop system with a 32-bit, 33MHz PCI, the GA25000T is the clear cost-effective solution, but would not be able to provide throughput at the level of the 3Com 3C996BT.
In an HPC environment, where sustained throughput is critical and the switch is capable of Jumbo frames, the SK9821 would be the best performer. In light of gigabit switching hardware that lacks Jumbo Frame support, a comparison of the 1500MTU results shows the SK9821 is still a viable choice, as is the 3Com 3C996BT which provides a more cost-effective solution.
Paul Gray
323 Wright Hall
University of Northern Iowa
Re:Text of Article (fourth section) (Score:3, Funny)
Re:Text of Article (fourth section) (Score:2)
Re:i'm sorry (Score:2)
Still, sometimes you only want to go a few feet between two servers or something and there you can't really argue with the price.
Re:Transfer speeds (Score:4, Informative)
Doing Math we can calculate that a full gigabit of transfer is 125 Megabytes a second. I think this is possible with high end hard drive technologies like SCSI RAID and speeds like this will probably show up in the desktop in a few years.
And, of course, not all data has to be written on Hard Drives. You could have a router or switch that will pass along a gigabit of packets a seconds but it certainly doesn't write them to the hard drive. You could for example but in a Gigabit Ethernet connection between two nearby buildings.
Tim
Re:Transfer speeds (Score:1)
Re:Transfer speeds (Score:2, Informative)
The Free On-line Dictionary of Computing (13 Mar 01)
prefix
1. The standard metric prefixes used in the SI
(Syst`eme International) conventions for scientific
measurement. With units of time or things that come in powers
of 10, such as money, they retain their usual meanings of
multiplication by powers of 1000 = 10^3. When used with bytes
or other things that naturally come in powers of 2, they
usually denote multiplication by powers of 1024 = 2^(10).
Here are the SI magnifying prefixes, along with the
corresponding binary interpretations in common use:
prefix abr decimal binary
yocto- 1000^-8
zepto- 1000^-7
atto- 1000^-6
femto- f 1000^-5
pico- p 1000^-4
nano- n 1000^-3
micro- * 1000^-2 * Abbreviation: Greek mu
milli- m 1000^-1
kilo- k 1000^1 1024^1 = 2^10 = 1,024
mega- M 1000^2 1024^2 = 2^20 = 1,048,576
giga- G 1000^3 1024^3 = 2^30 = 1,073,741,824
tera- T 1000^4 1024^4 = 2^40 = 1,099,511,627,776
peta- 1000^5 1024^5 = 2^50 = 1,125,899,906,842,624
exa- 1000^6 1024^6 = 2^60 = 1,152,921,504,606,846,976
zetta- 1000^7 1024^7 = 2^70 = 1,180,591,620,717,411,303,424
yotta- 1000^8 1024^8 = 2^80 = 1,208,925,819,614,629,174,706,176
------
BINARY BINARY BINARY! WE USE BINARY! Take a look to the right under "mega". mega- M 1000^2 1024^2 = 2^20 = 1,048,576. Therefor, 2^30 / 2^20 = 2^10 = 1024 megabits in 1 gigabit.
Now, what part of that dont you understand?
Re:Binary metric prefixes (Score:2)
Linux version 2.4.18 (root@yeti) (gcc version 2.95.4 (Debian prerelease)) #15 Wed Apr 3 02:12:16 AST 2002
hda: 60046560 sectors (30744 MB) w/2048KiB Cache, CHS=29785/32/63
hdc: 25429824 sectors (13020 MB) w/418KiB Cache, CHS=25228/16/63
Re:Transfer speeds (Score:1)
Nopey (Score:1)