Slashdot Mirror
IEEE Seeks Data On Ethernet Bandwidth Needs
itwbennett writes "The IEEE has formed a group to assess demand for a faster form of Ethernet, taking the first step toward what could become a Terabit Ethernet standard. 'We all contacted people privately' around 2005 to gauge the need for a faster specification, said John D'Ambrosia, chairman of the new ad hoc group. 'We only got, like, seven data points.' Disagreement about speeds complicated the process of developing the current standard, called 802.3ab. Though carriers and aggregation switch vendors agreed the IEEE should pursue a 100Gbps speed, server vendors said they wouldn't need adapters that fast until years later. They wanted a 40Gbps standard, and it emerged later that there was also some demand for 40Gbps among switch makers, D'Ambrosia said. 'I don't want to get blindsided by not understanding bandwidth trends again.'"
& they will come
We all wanted 100G. 40G is a waste of time.
Personally, ever since we moved beyond 10Mb I've been satisfied with LAN speeds. That's my $0.02 as an end user.
Ahh-hahahahahaha.... Moore's law guys. And before people flame me for misinterpreting the law, common usage is 'double the speed every 18 months'. It might be a misinterpretation, but its the most common usage in the world today.
/.
When was the last time someone significantly increased hardwired bandwidth?
I gotta stop drinking red wine, and then posting on
Who cares about our "needs"? Build the best cable you economically can today and it'll meet your bandwidth needs tomorrow. "SATA can only push 6 Gigabits, and that's from the drive to the motherboard!" is no excuse to not pass 6 Gigabits on your Ethernet cables. If you can push 600 Gigabits, that means the cable will serve you quite nicely for many, many years. I used to think that when I built / renovated my first house, I'd run Ethernet through the walls. Now, why bother? If I'd done this three years ago or so, I'd have likely used CAT5 and been pushing 100 Megabits reliably. By unplugging the Ethernet cable, I'd get 450% of that speed using the 802.11n MIMO tri-antennas in my MacBook Pro. The entire investment would be worthless because people built the cable needed then.
The iPad only supports wifi, so who cares about anything faster?
You and me we're goin' nowhere slowly
And we've gotta get away from the past
There's nothin' wrong with goin' nowhere, baby
But we should be goin' nowhere fast
'We only got, like, seven data points.' - That's, like, wrong, Dude.
Sure this will be used in datacenters and in between them. But for the humble desktop, haven't we passed the "good enough" mark at properly switched, full duplex 100 Mbit? anybody here needs more than 100M on his office desk?
10 ?"Hello World" life was simple then
It may not be needed this instant, but there's no such thing as too much bandwidth. Just off the top of my head, I can think a whole bunch of reasons one would want terabit Ethernet:
- For High Performance Computing and Database Replication -- both of these can result in systems that have performance that is almost entirely limited by the network, or very careful (expensive) programming is required to work around the network. Think about Google's replication bandwidth requirements between data centers! Cloud computing providers will have similar problems.
- Latency sensitive computing -- n-Tier applications like SAP have CPUs waiting for the network an awful lot. Users have to put up with multi-second response times because of the chattiness of the RPC protocols between the layers. Faster networks have lower latency, and when microseconds count, there's no such thing as too much bandwidth, even if the bandwidth isn't utilized.
- Converged Networking -- lots of people are merging their Ethernet and Storage (FC) networks, using iSCSI or FCoE. Fibre is already at 8Gbps, and SSD disks are going to create a situation where the disks have many times the speed of the interconnect. Note that bandwidth goes up as the IO response times drop, and we're about to see a drop from ~3ms for 15K RPM disks to under 1 microsecond for next-gen enterprise SSDs! SAN vendors are going to want 100Gbps ports soon, which implies 1Tbps aggregation ports.
- Bladesystems -- even today, a chassis can take 12-16 blades, each of which has 20 cores at around 3 Ghz. That's the equivalent of 1THz of aggregate computer power! The uplinks can become bottlenecks, especially when they are used for both storage and data.
- Movie and TV Studios -- there are digital movie cameras just around the corner that can capture 260Mpixel images at 24fps. That's something like 300Gbps if transmitted uncompressed! Throw in stereo, multiple angles, and then 1Tbps starts to sound like a good idea.
- On-Demand TV -- the aggregate bandwidth requirements of millions of households watching 4 hours of TV a day is just insane. Even with clever replication and multicast technologies, serious bandwidth is required to enable everyone to watch whatever they want, whenever they want.
Remember that networking is more or less fungible -- interconnects are all about moving bits about. At least in principle, almost any data cable could be replaced by Ethernet, or any similar technology. This 'unification' of networking is an ongoing process: Thunderbolt merged PCI-e and DisplayPort, Ethernet is starting to replace Fibre Channel, USB has eliminated a whole bunch of ports and cables, etc...
With that in mind, think of 1Tbps Ethernet not as something you'd plug a file server into, but as the interconnect between core switches for metro networks that feed 1Gbps into every house, or the campus uplinks for when 10Gbps to the workstations becomes reasonably common, or a link used by dozens of specialists to perform telepresense surgeries around the country from one central location, or things we haven't even thought of yet...
Terabit?? Terabit?! Gimme Zettabit Ethernet, give me sex...tillion bits per second, baby!
Come on guys. Powers of 10! You can't be going and moving from my powers of 10 wired Ethernet speeds, how will I do the simple math!
1 -> 10 -> 100 -> 1000 -> 10000
Easy maths! Say no to 40Gpbs.
i'm wondering if youve tried different tcp congestion control? there are many many choices and options, some which appear to be appropriate; http://datatag.web.cern.ch/datatag/howto/tcp.html discusses things like increasing the transfer queue, although you might not want to do this, and even the opposite for particular qos queues. this line is interesting; "If the buffers are too small, like they are when default values are used, the TCP congestion window will never fully open up"
time flys; 10+yrs ago i had a modem sharing setup where anyone on the network could cause the modem to dial and then everyone on the network could share it until the connection was lost. the log could be processed later to count the number of ph calls each person was liable for and so the local calls were almost all accounted for where the remainder being divided between house mates. then a couple of years and houses later we'd just gotten adsl2+ and wanted to share it between 4 or so people in a large house, i had the router in my room and so experimented with the linux qos.
to this day i believe that isp's throttle via dns. allowing certain people to torrent as hard as they could without causing udp 53 packets to get dropped brings a massive improvement for everyone. then setting up a hierarchy of qos queues and tinkering, so that the outbound traffic is limited to just less than the actual bw and then allowing 53 and other realtime traffic the highest prio. but i cant say i've seen much actual benefit from congestion control, so i'm wondering if you or someone else has found benefit??
Not literally on the "new thing," but stop making competing ports. Start and then end the next generation port format war as quickly as possible, and everybody get on board with either USB3, Firewire 3200, or Thunderbolt as quickly as possible. Computers should have one row of identical ports that work with everything. We need to get over the idea that certain 1's and 0's need a different shaped plug than others.
Can anyone tell me how to set my sig on Slashdot?
The user should notice no delay or lag anywhere, performing any task. This goes not only for bandwidth but operating systems and applications.
Obviously there are physical limitations and ultimately, there are compromises to be made but the above should be a design goal always.
I won't notice (and sure as hell won't pay the premium for) a huge increase over my cat6 home connection for anything I do shy of backing up a complete drive in a few seconds instead of just scheduling it while we're at work.
The problem isn't on my side of the gigabit switch. Find me a carrier that can get close to the limit for even the ancient 10/100 spec let alone a gigabit, then we can talk about a possible faster ethernet.
the faster the better, then Telecoms won't be able to nickle and dime us the whole way into the future.
And we won't have to hear their bullshit about content "hogging their pipes"
This isn't about home use though; consider an office, a render farm or other heavily-multiuser environments. There are already real world situations where the network bandwidth is the bottleneck; it prevents a render farm adding more nodes, or forces a larger office to split their networks up (adding to complexity, hence reducing reliability and security).
Those are the needs that need addressing; if the consumer service providers aren't able to justify the expense of upgrading their infrastructure, they won't. That doesn't mean the capability shouldn't exist for those who *do* need it.
Thanks to us, you had gigabit as an option in the last decade.
In the mid 90s, we had full duplex 100BaseT and had to box the ears of IT people who believed it was enough. We got 1GbaseT to the desktops before the end of the 90s, when PCs could already saturate 100baseT with an SSH connection, and now we've stagnated again because IT cannot see past the end of their ancient NFS servers. (Why would anybody need something faster or more reliable than our herky-jerky NFS and NIS servers?... sigh.)
I want 10GbaseT to the desktop, so we can get back to saturating disks over one link again. Right now, a laptop SSD or a trivially small RAID workstation has double or triple the bandwidth of a 1G link, so the link becomes the bottleneck during backups, replication, or development VM imaging.
... when the ISPs have barely even scratched the surface of getting megabit to the home.
What the IEEE needs to work on is technology that makes it easier to bring a few hundred megabit to the home. Whoever it was that said no one needed any more than 640kbits to the home was an idiot.
now we need to go OSS in diesel cars
In my day we carried our own packets. 10 miles! In the Snow! Uphill both ways!
What we should have had all along was a system by which ethernet could dynamically adjust its speed in smaller increments to match the existing wiring capacity, both in terms of bit signaling rate on a pair of wires, to how many pairs are used (e.g. if I use 16 pairs from 4 parallel Cat 7 cables, it should boost the speed as much as it can and use them all in parallel). Of course actual devices can have limits, too, and the standard should specify the minimums (like at least 4 pairs required, additional pairs optional).
Sure, we need some new tech to get 1000 gigabit/sec. Fiber, no doubt. Multiple fiber? Better modulation? But whatever is done, THIS TIME they need to not set limits. Set a minimum and define the means/protocol for working up to even higher levels. And make this protocol one that can retrofit into older PHY layers so my 1 gigabit/sec network can run at 1.6 gigabit/sec or better if my cables and connectors are nice and clean.
now we need to go OSS in diesel cars
I want to be able to copy large files between machines on my desktop at the speed of the file systems... with today's disks that's at least 500mbit/sec, maybe more. 100 mbit is just 12 megabytes/sec. Remember that 6 Gbit SATA is displacing 3 Gbit SATA, and 5 gbit USB3 is starting to displace 480 mbps USB2 for a REASON. 100 mbps is simply too slow for a file server, even of the desktop NAS variety.
There is only one other potential bottle neck I can think of. That is what about the bus speed on the server's and workstations' motherboards? They can already get saturated with all the things we keep inside the case, i.e. multiple graphics cards, hardware raid with a lot of drives (for those that do this internally not counting external setups), etc.
For 10Gb Ethernet a PCIe card should be OK, but start upping the ante to 100Gb or more and the NICs will start needing a lot more resources on the system bus and compete with the graphics cards.
I use 1G ethernet @ home and have it 'topped' out as far as speed usage.
I get up to 125MBps writes and 119MBps reads over CIFS using Win7-64 and a Linux-based Samba server, and it's no where near fast enough to keep up with many apps.
I'd *like* to go 'diskless' on my Win7 box so all my files would be backed up on my server, but have to make do with only storing my home dir (docs, basically).
Even with that, a roaming profile can take about 5-10minutes/Gig to save when you logoff or logon (logon is faster if you have the files already cached locally, but it still takes about 1-2 minutes/gig to check that the file are up-to-date).
Most of the problem is due to network latency -- much of it in Windows, which may not be be helped by a faster network, with a faster network, it might make more sense for hardware manufacturers to build hard-disk interfaces that handle the low-level network I/O in hardware. Larger packet sizes will almost certainly be necessary (am already using 9K 'Jumbo packets' -- largest supported by my off-the-shelf consumer equipment (Intel network cards and netgear switches).
If disk-like interfaces become prevalent with the low-level network I/O in hardware, then Windows latencies won't be as much of a problem. But right now, how applications ask for data make a big difference. My fastests reads/write occur with 16MB I/O sizes or larger.
Some apps think they are running 'fast' by using memory mapped I/O -- which on windows gives you a 32KB read size. That reduces the throughput by 66% off the bat. A horrible offender: Mozilla Thunderbird doing IMAPS with I/O chunks averaging about 1.5-2K. A 23Meg file sent from Mozilla TBird takes almost 3 minutes to save to the 'Sent' folder using about 1-2% of the network bandwidth.
So it's pretty certain that hardware assistance will be needed to offload the low-level I/O for desktop PC's to get benefit from faster networks for most applications.
But given that, one could finally setup 1 home PC-server, and then get full desktop speeds off of thin-clients in the house.
Would be nice....