First Gigabit Ethernet Chip Demo
An anonymous reader writes "Broadcom demonstrated the
world's first Gigabit Ethernet transceiver chip for
existing CAT5 copper cabling yesterday at
NetWorld+InterOp '99. Packaged in a 256-pin TBGA, Broadcom
has begun delivering initial samples at $75/chip. No word on
when full production starts or
when to expect hubs, switches, or NICs based on the chip."
That's true.. actually I've heard it's more like 400-500Mbps right now in reality. That really sucks if you're looking to deploy at least 100Mb/sec to the desktop with at least a gig/sec backbone.
It would be a good idea to include a TCP/IP stack on a gigabit card, rather then a 100baseT wouldn't you think? That way the I/O and CPU can jus tspend time pumping the 126megs or so of data to the PCI bus.
I think that what is being discussed the next few years would be 133MHz 64 bit PCI buses that would do 1064GB of data per second, essentially requiring abandoning the legacy North/Southbridge stuff (for x86 -- everyone else has long since left). That and 266MHz or RAMBus RAM. We already have crossbar backplanes that will do 3+GB/s at 66MHz, so pushing it up a bit should be sort of easy (more of a issue than anything else). So, assuming that we have one of the cards doing close to 133MB/s, it shouldn't even saturate a PCI bus (let alone the backplane) and we could conceivably (I hesitate to say "easily") put four jacks on a card like we're doing now and two cards on each bus. Sadly, that means that I couldn't use the LAN at "wire speed" either, as even four Gb Ether cards would have a hard time keeping the memory refreshed. I think that we will be seeing this with the Alpha and RS6000 stuff first, but I think that this chip is only a little early. Now if we can get reasonably cheap ($5000 or so) 4-8GB DIMMs (allowing me to have 64-128GB of RAM on the board), I will be a happy camper!
Sure, 155Mbit ATM has better performance then 100Mbit ethernet under really high load.. But under lower load, ethernet is quite a bit faster (ATM cells are 53bytes!!!).
So if you say that ethernet is good upto 60% util.. Gigabittethernet runs at 1200mbits/s raw spped compaired to OC12/622mbits for ATM.. So at 60% where ethernet starts breaking down, the ATM would already be past saturated (.6*1200=720).
QOS?
You can provide QOS on ethernet/IP networks just fine.. It just requires fancier routing.. Since very few applications support ATM directly (almost no computer apps), you need the same kind of fancy routers to convert IP QOS into ATM QOS, so you dont win there..
The only place where ATM really wins out is for carriers who can't stand the kind of saving custs get from packet service.. They can t stand to charge you only for what you use..
--
Gregory Maxwell gmaxwell@martin.fl.us
Computer Network Spec.
Which still works better and is about the same cost, for equal quality hardware. 100Mb cards are shipping now from Madge, Olicom, IBM, and 155Mb cards will be out this next quarter. Gigabit Token is testing fine, and running at 900Mb, except on NT, which chokes at about 500Mb. That will be out in the first quarter of next year. 80% of the Fortune 500 still uses it, it works fine at 90% of capacity, and already does all of the QOS stuff that ATM does. And has for years. http://www.hstra.com has some data, so does http://www.networking.ibm.com/prodguide/tokenring. html, and http://www.madge.com/Token/TRHome.asp, and http://www.olicom.com and http://metalab.unc.edu/LDP/HOWTO/mini/Token-Ring-1 .html.
More and more today, ethernet is switched..
Features of ATM:
Heavy smarts in the nics/routers
Tiny fixed size packets (53bytes)
Big TELCO backing
Circut based (you open a circut of X QOS and Y bandwidth with Z delay, and your carrier can charge you by the sec, even if you dont use it)
Neat design.. But most see it as a plot by carriers to stop packet price savings (it is!). ATM is very expensive, and the services that it provides that most people need can be increasingly provided via IP QOS w/ overkill ethernet and fancy routers (which is alot cheaper then ATM because of massmarket power).
I HATE Ciscos high speed products.. They suck.
I use mostly bay stuff, I do run ATM, but I am phasing it out. Gig has better bang for the buck. Your QOS means nothing, because none of your apps will use it.. I bet you all your atm traffic is UBR and it's going to stay that way because the ATM groups worked hard AGAINST IP compatibility because IP is too open.
Nope, not 20m.. They modded the ethernet spec to make the minimum packet size 512B insted of 512b on *HALF-DUPLEX* links. They also added a burst mode that can combine multiple 512B frames into one for half duplex links. (it padds when it can't burst and the packets are too small)..
This extends the CD to 200m. (note! none of this 512B crap happens for full duplex) I've got dozens of gig ethernet links (litterly) and I've never seen one half-duplex.
Actually Gig ethernet has a raw throughtput of 1200Mbit a second. With packet overhead it provides 1000Mbit at application level. The 400-500mbit numbers you are hearing are the limitations of servers.. The fastest single computer I've seen on gig ethernet is a 21264 running linux that was able to do 490Mbit transfers.
The stupid E450's at work can't even hit 200mbit/s over gig ethernet though.. But gig ethernet and the switches really can push that much bandwidth.
If you have offices and over 1000 feet of cable, replacing that is NOT an option when original cable installations could have cost in the thousands for multi floor buildings.
For the simple reason Coax isn't full duplex (token ring).. and so only 1 machine can talk at a time (the one with the token). This would jam up the works alot more the bigger the 1Gb/sec network grew.. with alot more packet collisions, and what have you.. effectively dropping the max speed to a lower rating than it could be on a more efficent cable.
Try the Netgear GA620 ones
http://netgear.baynetwork.com
We pay about 300$ USD for them
I run multiple gig ethernet links to 80 sites..
Sure, all my links are 5Km (except for some 30Km backup jumps).. Works great.. Bandwidth is not an issue, even with V/IP and video traffic.
I have a PRO200 at home, and it can saturate two 100mbit links serving out files to three PII clients using 2.2.6 and KNFSD..
Perhaps windows can't. (Hell, we've got over 400 suns and the even the E450s can't hit 11MB on 100bt).. But Linux can, even on older hardware.
This is why we used coax cable back in college, when I and some friends decided to take matters into our own hands and string up ethernet between our dorm rooms. We were barely able to make 500m work! 100m is useless for anything larger than a very small company's office LAN.
I dearly, dearly wish sometimes that 100b was available in coax flavor.. 100b5 would rock my world.
Actually Gig ethernet has a raw throughtput of 1200Mbit a second. With packet overhead it provides 1000Mbit at application level. The 400-500mbit numbers you are hearing are the limitations of servers.. The fastest single computer I've seen on gig ethernet is a 21264 running linux that was able to do 490Mbit transfers.
The stupid E450's at work can't even hit 200mbit/s over gig ethernet though.. But gig ethernet and the switches really can push that much bandwidth.
Why aren't we using coaxial cable for this stuff? It's better shielded, it's cheaper (premade cat5 cables often sell for >$1/foot), and it runs longer distances. 10base2 traditionally runs in a bus configuration which is not suitable for larger networks, but I can't think of any reason a coax hub couldn't be invented.
100BaseTX is supposed to go 100 meters from hub to host, but I can't get a reliable signal with anything beyond about 80 feet. I tried 3 different cables (all homemade, but reliable at shorter distances) and every type of hub and NIC I could get my hands on. Is there some secret to it?
I wish everyone would just bite the bullet and make everything fiber based. The prices will drop a lot when it is more mass produced, and we won't have to mess with a semi-reliable medium.
This is what I understand about ATM an Ethernet:
- ATM is conection-oriented network, e.g. you request a channel from starting point to end point and, if granted by network, you get a communications channel with guaranteed speed, delays, etc.. (this is called Qos)
- Ethernet is packet (frame) technology, and it is not-connection oriented.
- Ethernet is at Layer 2 (by ISO)
- ATM is full networking technology at Layer 4, so you could compare it (functionaly) to Ethernet+IP
- ATM is thus always "switched", so it does not need shared media access techniques (collision detection, etc..)
- Ethernet (also Gigabit) is "switched" and "shared".
- With shared Ethernet you can not guarantee no Qos and it saturates at about 65% of linespeed.
- With switched (end-to-end!!!) Ethernet you can, to some extent, quarantee QoS.
- To put it simple: ATM switch offers as much functionality (if not more) as nowadays modern (linespeed) Ethernet switch-routers. The price per port is comparable!
- ATM's misfortune is that all today's applications use IP stack, so all vendors are seeking a way to use ATM as a transport medium for IP, instead of using it natively. (MPOA, LANE, CLIP..) They are mixing packet network and conection-oriented network.
Real world comparison would be Post network against Phone (Fax) network.
Please correct the above list.
Peter
I had to put it on, "get rid of that pistol".
"Pray arm me further by your reply" Winston Churchill
Since it is the same range as 10/100baseT, it IS a big deal for upgrading any current LAN. In many cases, the cost of new cards and switches is nothing compared to the cost of running new cable. I can think of a use rught now where we have a 100baseT running between floors. I'd really like to up the bandwidth in the near future, but I don't want the hassle and paperwork of getting the fiber run.
For new installation, fiber may still be the best bet because of the long runs it supports.
Just "for reference", FreeBSD currently supports gigabit adapters based on the Tigon chipset (eg. those from 3Com, Alteon, etc.). Initial benchmarks show a useable TCP bandwidth over 500Mbps and UDP bandwidth over 800Mbps. For a server feeding a gigabit-capable switch, this is a useful improvement over 100Mbps ethernet.
Given that current pricing on fibre-based cards is well under $500, expect to be seeing Gb ethernet making a real play very soon.
Isn't that just the part connected to the physical wires of the network? The core chipset doing DMA and other things still could inflate this 75 buck just to todays' level :)
"Ten years from now, they could do it in a few seconds." -- The Racketeer of the Hellfire Club, 1993, Phrack 42
10b2 is transciever style... the single pair transmits and receives. 10bT is different in the sense that there are seperate pairs of wires to do the talking and receiving.
:-)
:-)
I won't say it's impossible, just not possible yet.
By the way, I have heard that the realisitic throughput of gigabit ethernet is closer to 6 or 700mbps (Communications Systems Design trade mag). While not truly gigabit, it is still pretty effing cool if you ask me.
Of course, >99% of Gigabit Ethernet is full-duplex so there are no collisions. This is partly because, up until now, all GigE was fiber-based, and most fiber topologies have one strand for transmit, one for receive (i.e. no way to collide). If you did build half-duplex, I believe the collision domain would be like 20 meters, not very useful.
:-)
The reason Broadcom's chip is so complicated is that for full-duplex GigE on copper, all 4 pairs in the cable are used, _in both directions_. This means the chip uses fancy DSP techniques to subtract what is transmitting from what is receiving. It handles FEXT and NEXT (far-end and near-end cross-talk) as well.
The only other concern is that the end-station just cannot create frames fast enough @ 1518 bytes, so there is a proposal for jumbo frames to enable endstations to lower their rate of frame generation. Still, for decent TCP stacks you can see 500-800 Mbps right now, which is a good bit better than 100Mbps.
The ATM fixed-53B cell is an interesting idea, since it allows for uniform memory allocation per cell (versus ethernet, where you don't know if you need 64 or all the way up to 1518), but in hardware, often the implementation for Ethernet is to use linked-lists of buffers (say of 128B) which will have good efficiency.
Problems like these can always be solved, and Ethernet is cheap and standard.
Death to ATM!
Wrong order of magnitude. Theoretically, 32 bit, 33 MHz PCI _could_ do it, but it won't happen at max. This is why new systems are comming out with multiple PCI busses, and a case for Alpha (even Apple) systems, a 64 bit PCI bus, so that eth traffic doesn't kill your drive or graphics bandwidth. You'll need expensive switches to get the max out of the pipe.
even if $75 is just a single chip, the card can't be thathbad.. ) - we're going to choke the net to death.
256 pins on a chip may take up significant card reale-state. It will be a busy board! I would imagine it could really make use of a 100MHz PCI bus too! I might expect a new generation of motherboards to appear in the future. Get your credit cards ready...
token passing and ATM networks are superior to collision detection, but it's a price performance thing. Ethernet is an open standard and it's CHEAP (and fast).
Not sure where you got the 75% figure from, but frm my experience once ethernet hits 50% utilization it is hosed (time for a switch).
support gun control: take guns from cops
It's interesting to note that with 4x100Mb adapters around 350Mb/sec is the figure quoted for NT performance (which is great for that test, but crummy for Gb ethernet).
support gun control: take guns from cops
1 Gigabit/s, bah humbug! What I want is 10 Gigabit/s like the folks at Lucent/Bell Labs are playing around with. No sh*t folks, 10!
They'll be showing this off this week. You can get the info about a LAN and a multiplexer.
This sort of makes our workplace upgrade to a 100Base-T switch look sort of feeble.:)
This is only ten times the bandwidth of 100Mb Ethernet, and those are available cheap as daisies, so this is no huge stretch.
And it's for LANs, Local Area Networks, not modems to connect to ISPs.
Seems to be some confusion here, as if suddenly homes will be getting a billion bytes a second net connections.
--
Infuriate left and right
If you're looking for info on optoelectric computing, check out the research at the University of Colorado.
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
Richard von Weizs
Maybe because fiber sucks and is much more expensive. You can still by 100Mbps fibre stuff - check out the prices.
I would guess that most of the early 100Mbps short range fiber installations have been pulled in favor of cat5. 1000BaseT opens a huge market - I would suspect that prices will soon fall to around $1000 per switched port, which is affordable if you need it.
--
Business. Numbers. Money. People. Computer World.
Sure, it's only 800Mbit/sec, instead of 1000 (or is it 1200? I forgot), but that's AFTER the headers...
And having nice features, like NO MTU is quite nice. I remember sending 40MB packets over our
switches straight to a frame buffer... now THAT was sharp animation...
And seeing an network of Suns (with my companies SBus cards and switches!) and Crays, that had, in 3 years of running, NEVER dropped a single IP packet.
Sure, the cable (in the copper inplementation) is over $300 for a 3 meter one, and you need two of those for a full connection, but it sure was a well-engineered technology.
I only wish I had stayed there long enough to see the HIPPI64 stuff...
Ce n'est pas une signature automatique.
So you're sending the HDTV signals non-compressed? That doesn't seem like a particularly bright thing to do.
Do you have any concept of how much it would cost to pull out all the cat5 and replace it with fiber in any significantly large organization that would consider gigabit Ethernet?
Most Ethernets seem to start having collision problems above 50% utilization. The worst case was a Sun
implementation of Ethernet where the wait time after a collision was fixed at the minimum, resulting in the NICs
dropping into lockstep when collisions started and network utilization dropping to 0%.
Then the SUN implementation was not to spec. True Ethernet devices are supposed to wait a random, or pseudo random, time before trying to retransmit after a collision. I'd say their implementation was broken.
Also, if you are talking full-duplex connections, there is no such thing as a collision anymore. Since you can transmit and receive at the same time, you can't have a collision. Buffers can backup on the switches and you could drop traffic, but you wouldn't have a "collision." "Good" switches can also do flow-control, so that their buffers will not overflow. See the 802.3x spec.
Looking at the Gigabit Ethernet Alliance FAQ, it looks like they extend the carrier time and slot time to 512B from 512b. This, in effect, makes the minimum packet length 512B instead of 64B (The official min packet length is still 64B but it will pad it to 512B) for non-full duplex devices. So, unless you have full-duplex connections you are not gaining that much. However, it looks like they try to make up for this with the packet-burst feature, which allows stations to send out multiple consecutive packets without giving up control of the line (supposedly up to the 512B slot time).
Damnit, one of those things could run my school's *entire* network!
That thing KICKS ASS!
~Linux is not The Answer. Yes is the answer. Linux is The Question.
I don't know about heat or power, but I know that the powers that be look really closely at the bottom line.
CAT-5 is cheap (by comparison to optics) especially if it is already strung throughout the building. It can be cut to size, and you don't need to hire an optics-aware tech to handle it.
The installed base of CAT-5 wiring is significant, and presents a large investment - so as you'd say, using it is a major benefit
Also there's all the supporting hardware. Even if you make the investment in fiber, and string it throughout your building, you've got to tie it all together, and that requires special (non-copper) equipment. Fiber-handling equipment of any kind - be it routers, switches, couplers, whatever - is again more expensive than the CAT-5 counterpart.
Conversely, a new installation is still likely to shy away from fiber, because this is still new tech, and nobody wants a lemon, or a token-ring, or BetaMax.
Management will always look at the market inertia, and initial and running costs when making these decisions, and the sensible choice in those terms is copper ethernet.
-- What you do today will cost you a day of your life.
Now THIS we can use around the office.
The hell with Win2k, GB-ether is nice for all those big CAD drawings, DB shuffles, Quake games!
Now, about that Internet backbone bandwidth:
If I have GB-ether on my desk, and so does everyone else (even if $75 is just a single chip, the card can't be that bad.. ) - we're going to choke the net to death.
Nevermind that a single PC can't pump data out that fast, a cubefarm of them can. We need significant backbone bandwidth improvements and faster routers.
Where's those danged pure-optical chips?
-- What you do today will cost you a day of your life.
The problem with Ethernet at high utilizations is collisions. Only one station on the Ethernet can transmit at a time, but due to signal delay the station can't tell when it starts to transmit whether another station is starting to transmit at the same time. When two try to talk at once you get a collision and they both have to stop, wait a short, random amount of time and try again. The more of your bandwidth you're using, the greater the chances of this happening. If it happens too much, utilization goes down because all the stations spend more of their time waiting for their last collision to clear than in actually transmitting. ATM, being effectively a point-to-point network at the physical level, doesn't suffer from collisions.
Most Ethernets seem to start having collision problems above 50% utilization. The worst case was a Sun implementation of Ethernet where the wait time after a collision was fixed at the minimum, resulting in the NICs dropping into lockstep when collisions started and network utilization dropping to 0%.
Yes, Sun was horribly out of spec. Another case of a company deciding that a feature was hurting performance without bothering to check why that feature was put in there in the first place. See also remove of "performance-robbing" slow start and exponential backoff in TCP stacks.
As for full-duplex, good switches eliminate collisions but only as long as all nodes are connected directly to a switch. Throw in some vanilla hubs and a bunch of older network cards and you're back to collisions ( albeit the collision domain is drastically reduced ). Dropped traffic also has an effect on throughput even though you aren't generating collisions, all those retransmits eat up bandwidth too.
Try *ONE*. Different transciever styles for different media, and all your are *really* doing is propagating RF on the thing anyway.
"All those tubes and wires and careful notes!"
1GB.. I don't think my computer could handle that much info, but it's still cool. Wonder if they could apply these DSP techniques to 10b2..
"Windows 98 Second Edition works and players better than ever." -Microsoft's Home page on Win98SE.
I ate my tag line.
-=Ellis (D)25=-
Yes it would be good to bring those to technologies together. This could help out beuwolfs too! Think about it.. 1gb/s plus low cpu usage!
Some one had to say it.
"Windows 98 Second Edition works and players better than ever." -Microsoft's Home page on Win98SE.
I ate my tag line.
-=Ellis (D)25=-
Ethernet is usually a non-switching network, so it tends to be slower.
ATM is high speed switch network.
Ethernet has diffrent packaging signals from ATM.
I hope I got my facts straight (Long story)
But reason for this would be for cheap solution for putting in a bigger back bone in building, instead of ripping out copper and installing fiber.
"Windows 98 Second Edition works and players better than ever." -Microsoft's Home page on Win98SE.
I ate my tag line.
-=Ellis (D)25=-
NEC's ATM stuff. I would post a link, but they have not put up a webserver yet..
atmlab.com
"Windows 98 Second Edition works and players better than ever." -Microsoft's Home page on Win98SE.
I ate my tag line.
-=Ellis (D)25=-
After reading this, I wonder why one would choose to use the new gig over copper technology rather than the existing gigabit ethernet over fiber. Since the 1000 base T uses all four wire pairs at a high frequency, there is significant power consumption and heat. Am I way wrong in thinking that the only benifit of 1000T over fiber is that existing cat-5 wires can be used? Or are we expecting a big price difference for NIC cards and switches?
I would add that I think the IP protocol fits much better over simple ethernet than it does with the complex, fixed cell, connection oriented ATM protocol. The new gigabit ethernet layer 3 switches that route in hardware and foward packets at wire speed should limit the use of ATM to very specific applications.
All vendor/consortium links I'm afraid...
Sorry, no raw performance numbers :) I'm also not a networking guru...
Back when I was looking into things, I found a Lisa98 presentation by Curtis Preston called "Using Gigabit Ethernet to Backup 6 Terabytes" -- in his presentation he referred to gigabit ethernet as really being "200Base-T" based on the results he saw. Much depends on your TCP stack and support for jumbo frames, etc. etc.
The ATM vs gigabit ethernet debate totally depends on what "situation" you are talking about. ATM has alot of advantages and seems to be the fastest shipping bandwith available now (OC-48,etc.) It also has nifty billing/accounting/garanteed bandwith abilities and can easily handle both delay sensitive (isochronous) data like streaming media as well as more traditional computer network traffic.
I guess it all comes down to how you want to use it -- I chose Gigabit ethernet for my DNA crunching alphaservers because I knew I was going to have a small number of hosts carrying IP traffic only -- no need for extensive WAN or MAN interconnects or thousands of circuits, no need to deal with isochronous data alongside computer traffic and no real urgent need for the accounting/management features of ATM.
The biggest reason for my choice of gigabit over ATM was inhouse experience -- my group of biogeeks and the corporate IS people have tons of ethernet experience and no real ATM experience. This is why I think gigabit is going to _really_ take off in the LAN/intranet space-- being able to use your ethernet-aware people AND your existing Cat.5 copper wiring is very very attractive.
just my $.02
"ATM, being effectively a point-to-point network at the physical level, doesn't suffer from collisions."
Suffering isn't really a great term for what is going on. Ethernet uses a shared medium (coax or twisted pair) so it uses the collisions as an arbitration mechanism. On a lightly loaded circuit, there is no arbitration overhead. The mechanism you describe for collisions is correct, and I imagine that when you compare performance to ATM including arbitration (routing, circuit set up, Not too sure about ATM) that performance looks a bit better.
Yes on a heavily loaded (60% - 70%) Ethernet circuit stations have to wait a bit longer for access to the medium, but with a light load, there is no arbitration delay (start transmitting, check for collisions later).
A heavily loaded ethernet circuit can eaisly be divided in two (or more) with a bridge (switch), yielding two lightly loaded circuits, and better performance overall.
Jeff
I was reading some articles on this topic and found some interesting discussions about gigabit ethernet vs. ATM transmission.
In a nutshell, one article suggested that ethernet began to perform less and less efficient the more data was pushed through the ethernet pipe (up to about 65 to 75% overall utilization), due to the differing packet sizes or something like that.
The article then went on to say that for large pipes of data, the single cell-? size of an ATM packet allowed it to scale "much" better than the ethernet network. They said up to something like 95% utilization.
Maybe gigabit ethernet wouldn't be as good of a decision if ATM worked better in this situation. Can anybody explain the difference to me? If you happen to have performance numbers, please post them.
LOAD "SIG",8,1
LOADING...
READY.
RUN
That's really cool, and you're right, for your particular application, ATM is going to kick the bejeezus out of any frame-based tech.
And that's the real, point, isn't it? For some applications, ATM makes good sense. I wouldn't implement anything but, if I needed to run concurrent media streams alongside my data. But for me, I just need a way for rows and rows of servers to get to the backbone with as little contention as possible. Pretty much all my frames end up as ether (at the server), so why try to change things?
Once again:
What do you want to do?
What software (network, layer2, whatever) does that best?
On what hardware does that software work the best?
^how to build an infrastructure^
On the surface, most people would want to keep their existing wires, and not have to replace them. This is, of course, a reasonable concern, and of significant importance if it meant re-wiring a building.
However, the time when every PC needs a Gigabit connection is still a while off. 10Mbit is still sufficient for the vast majority of networked PCs. The vast majority of network performance problems stem from frequent collisions, which in turn results from too many users hooked upto one port of a switch. Only a few will truely benefit from 100Mbit.
Most small to medium size companies can easily run all their servers off single 100Mbit ethernet connections, and have no problems at all. 1Gbit ethernet cards are really only needed in enterprise servers, and it will probably stay that way for some time (at least 5 years). Most PCs can't even saturate 100Mbits while providing or storing/displaying meaningful data.
I really don't see the problem with laying new lines between a handful of servers and switches which are normally placed in a central server room.