Mixing Gigabit, Copper, and Linux
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."
How'd they fare?
/. effect.
/.ed to oblivion? That's not interestng, that's anti-climatic - I know what happens before I get to the story. Oh well...
Not terribly well against the
Interesting results to say the least.
Lessee, a story about increasing bandwidth on a server
Soko
"Depression is merely anger without enthusiasm." - Anonymous
Could you post a summary? That must be about the fastest /.-ing I've seen. What'd that take, about 5 minutes?
Just fyi, Macintosh 1000BaseT ethernet controllers go directly to the memory controller, bypassing PCI altogether..
Care about electronic freedom? Consider donating to the EFF!
Stay away from cards that don't have PXE and cards in which the driver won't compile into the kernel (as opposed to a module) if you plan to do easy installations or mount root off the network. In other words, stay away from Netgear and some 3Com cards (I haven't tested others), and play it safe with Intel.
Well, check out the docs first off. It's hard to get much out of GBit, since most of the utilities don't call the socket open with properly sized buffers/window/whatever.
/* 8192 */
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.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Well... copper is cheaper than fiber for the moment. I'd hate to think what my 50 meter run from my router to the second floor of my townhouse would cost if it was fiber.
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...
"Oh my God. This is terrible. This is the end of my Presidency. I'm fucked."; ~ Donald J. Trump
apparently Pricewatch.com has D-Link 8-port 10/100/1000baseT auto-detect switches listed for under $150!
;).
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.
> Are we even to the point when a normal PC could handle Gigabyte?
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.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Are we even to the point when a normal PC could handle Gigabyte? And if so, why not use optical?
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.
you, sir, are taking a huge slurp from the karma tit today. Congratulations to you! Cheerio.
The cards are well priced for home use, and CAT5E cabling is cheap too. The problem with gigabit ethernet is not the cards, it is the lack of switches or even plain hubs at an affordable price point. There are lots of switches out there with a single gigabit port, but even those are a couple of hundred dollars. If you want multiple gigabit ports, you are looking at more than $600 for the bottom rung products.
When information is power, privacy is freedom.
Someone needs to learn the difference between a gigabit and a gigabyte....
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
Omnia vestra castrorum habetur nobis.
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.
There was another review of GigE performance in the IEEE Network Magazine last year.
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. 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 to download the entire page (images and all) in one shot.
20 January 2017: the End of an Error.
First, you can't just stick a gigabit card in a machine and expect it to work at full capacity. The basic design of ethernet was not really designed for gigabit speeds, but we've managed to squeeze it out - barely.
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
Oh, you're not stuck, you're just unable to let go of the onion rings.
Wow. That makes any analysis tough, when performance measures fail to satisfy the Reflexive Property!
Brian
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!
Tired of FB/Google censorship? Visit UNCENSORED!
The fastest pci gets is 66mhz 64bit. Thats 64 bits per clock cycle, 66M clocks per second....4.224 Gigabits. I'd say thats a little higher than 1 Gb.