Gigabit Ethernet: Dude, Where's My Bandwidth?
-
Page 1:Introduction
-
Page 2:What Makes A Gigabit Network? Cards, Cables, And Hubs
-
Page 3:First Test: How Fast Is Gigabit Supposed To Be, Anyway?
-
Page 4:Network Speed Limiting Factors
-
Page 5:Test Systems
-
Page 6:Network Tests: Setting Our Expectations
-
Page 7:Network Tests: Are We Getting Gigabit Performance?
-
Page 8:Testing-Cabling Factors
-
Page 9:Conclusion
I was in no hurry to upgrade my home network from 100 Mb/s to gigabit speed, which is odd when you consider how much time I spend waiting for file transfers. That's because when I spend money on PC upgrades, I think of the components that offer an immediate performance increase in the applications and games that I run. Putting cash towards things like video cards, CPUs, and even peripherals is almost like buying toys for myself. For some reason, network components don’t inspire the same amount of excitement. Indeed, it’s harder to let go of hard-earned money when it feels like an infrastructure investment rather than a self-gifted advance birthday present.
Inevitably, however, my high-bandwidth networking demands were making it obvious that 100 Mb/s weren’t going to cut it anymore if I valued my time. All of the systems I was running at home already had gigabit network controllers built into their motherboards, and I remember looking into the rest of the hardware shopping list that I needed to step up my network to full gigabit speed.
No, a gigabit network does not have to be this complex
When I was all done collecting the pieces, I remember copying a large file over the old 100 megabit equipment, which took about a minute and a half, and then upgrading to the gigabit network. After the upgrade, it took about 40 seconds to copy the same file. It was a nice performance boost, but not quite the 10 times difference between 100 Mb/s and 1 Gb/s I was expecting.
What's with that, anyway?
Let's find out what's going on by examining the basics. If you're a network wizard and you know all about MTUs, frame sizes, and the minutia of optimizing a network, this article will be somewhat elementary reading. But if you don't know much about networking except that there are computers and cables involved, read on. We’ll be going over the fundamentals of gigabit networking, the variables that will impact the network speed, and what a home user can do about them to get the most out of Gigabit Ethernet.
11% loss due to negotiation and overhead on a network link is about ballpark for a home test.
I'm ok with this piece, it isn't and injustice or it isn't wrong in any way IF you look at who it is addressed to. Remember the KISS rule guys.
For example: "Cat 5e cables are only certified for 100 ft. lengths"
This is incorrect. 100 meters (or 328 feet) maximum official segment length.
Did I miss the section on MTU and data frame sizes. Segment? Jumbo frames? 1500 vs. 9000 for consumer devices? Fragmentation? TIA/EIA? These words and terms should have occurred in this article, but were omitted.
Worthless writing. THG *used* to be better than this.
Thanks for the article. But I would like to ask how is the transfer speed measured. If it is just the (size of the file)/(a time needed for a tranfer) you are probably comsuming all the bandwith, beacuse you have to count in all the control part of the data packet (ethernet header, IP headrer, TCP header...)
Blake
Hope this is cleared out.
For example: "Cat 5e cables are only certified for 100 ft. lengths"
This is incorrect. 100 meters (or 328 feet) maximum official segment length.
Did I miss the section on MTU and data frame sizes. Segment? Jumbo frames? 1500 vs. 9000 for consumer devices? Fragmentation? TIA/EIA? These words and terms should have occurred in this article, but were omitted.
Worthless writing. THG *used* to be better than this.
Really? I thought Cat 5 wasn't gigabit capable? In fact cat 6 was the only way to go gigabit.
11% loss due to negotiation and overhead on a network link is about ballpark for a home test.
Anyway, many difference factors will affect the transfer speed. The most accurate test need to use Ram Drive and have to use powerful machines to illuminate the machine bottle neck factor out.
First of all, there's the 10b/8b encoding, so an 8-bit byte is encoded to a 10-bit unit. Then there's a concept of invariable frame sizes, whereit might be possible that a TCP/IP packet spans two frames, filling 100% of the first and 1% of the second, it means 50.5% efficiency. Third, every frame is payload only in part, rest is taken up by header information, footer and CRC. It's not much, perhaps about 5% of the frame, but it can get noticeable.
First, you have to divide by 10, not by 8, to get the speed in bytes/second (ie. 100 MB/s, not 125 MB/s).
Second, if you transmit a lot of inefficient frames (networking programs aren't exactly frugal about bandwidth when they have gigabit ethernet, and next to none are actually optimized in any way for it), you might lose up to half of the bandwidth.
Third, when you factor in the frame level overhead, you might end up with maybe 40-45 MB/s of the promised 100 MB/s...
Fortunately, a lot of these issues can be resolved by optimizing software and firmware to take advantage of the available bandwidth and idiosyncracies of gigabit ethernet.
Testing with a different file for ram to ram then used in the other tests really show the errors in these tests.
I'm ok with this piece, it isn't and injustice or it isn't wrong in any way IF you look at who it is addressed to. Remember the KISS rule guys.
I think the RAM disk was a good idea to do a maximum throughput test in using real world data copies but that was the only good thing about the article that I can see.
One the other hand is is worth mentioning, that transfer speed over gigabit network from disk to disk, depends on the files size transferred and number of files transferred.
It's one thing to copy over network a 4 gig file. And is totally different to copy 40k+ files totalizing 4 gigs. For the latest scenario, performance will take another hit due to increased I/O overhead @ disk level.