Slashdot Mirror
Future I/O Standards
hardave writes "Here's an interesting article from Performance Computing about future I/O protocols and standards." This piece talks about the most recent gathering of the minds about I/O. In the end, it means what we've expected all along; faster throughput, and the benefit of creating open standards.
Serial is taking over. Practically anybody could have predicted that. Firewire, USB, etc...
Two very intersting points, however, are a) They're considering Fibre in a consumer application and b) they're very seriously considering security of the link.
I haven't worked terribly much with fibre but just how sturdy is it? They're claiming up to 10kft which is a long long way... people are gonna run this under carpet, trip over it, the cat's gonna chew it... I thought that fibre was a pretty resilient technology from an EMI point of view, but what about the Home Factor? Copper wires are usually pretty good about being tripped over and ripped out of sockets. What of fibre? If you kink a fibre cable, what happens to it?
The other point was security. Basically they're arguing over two methods. One is "closed-source" and switched, while the other is "open-source".
They go as far as to say that a closed implementation is a big flashy waving sign for hackers, as it's an irresistable challenge. They're bang-on there. I mean a fast standard that doesn't need 200+ connections? I'd be all over that in a heartbeat! It's refreshing to see a gathering of industry leaders actually see that aspect.
... I think it's neat... the philosophy for years has been more parallel connections. Transfer more per clock and you up your bandwidth and therefore your throughput. What's next? Serial processors? A couple megs of cache on the chip, maybe a serial bus to system memory, antoher to system I/O and one to the video subsystem? I mean they're talking throughput greater than PCI 2.1 here... Why NOT reduce the CPU to a dozen pins?
The fact that Serial is much, much less tricky to physically handshake is the reason we've seen so many R&D development dollars poured into it.
:-)
/etc/shadow, completely independant of the directives from the underlying operating system. This must remain a top priority of I/O designers, and actually stands as a reason for separating heavily trafficked interfaces from less traveled, more justifiable to lock off ports.
Actually I think all the money's being poured into the design of fast serial because parallel interfaces need to be short and very rigidly controlled to be fast. And to get faster you need to add more lines (beyond the double-edge clocking and stuff). Serial offers more in this arena, and if you need to be faster than that yet, you can parallelize individual serial lines.
I won't argue with you that there's an agenda. However I don't see what's necessarily wrong with it.
Make no mistake--Serial may be awesome, but this is a new thing. The general attempt has been to spooge parallel design style into a serial interface.
This isn't necessarily true. Serial's been around forever. This LVD stuff you mention below is a relatively new commercial venue, but the idea for it has been around for quite some time. I believe some of our industrial controllers used the idea of a differential serial signal to get the point across a noisy environment and with low EMC for years now.
The fact that someone (TI and National are the biggest ones here) has thrown the design into a wire 'n go chipset doesn't make the whole idea new. Cheaper and faster, yes.
(how many of these serial systems just have a "magic chip" that expands the incoming serial stream into the parallel bus everybody knows and loves?).
I was taking the article a different way. Replace the parallel busses with serial busses. Right up to the memory/cpu/video subsystems. In other words, make the controllers serial themselves. As a previous poster mentioned, the computer now becomes a series of NCs.
The conversion from serial to parallel wouldn't happen until right inside the silicon. and even then it can be split off properly to maximize chip space (i.e. split off the bits that are required for 'x' to 'x's spot, and for 'y' to 'y's spot. You aren't converting the whole thing to parallel at once, just where necessary. And if done correctly, the subsystems inside the die could possibly deal with the data at a lower data rate.
Oh my. Is that so. I would have thought it was easier with those aforementioned 90 pins of parallel joy to have quite a few streams of data traveling over physically independent traces, as opposed to a multiplexed, time lagged, two wire system, which incidentally has no requirement to be bidirectional at all thank you very much.
90 pins of parallel joy with independent pins are a waste of space and design time. Let's say you've got 6 slots sharing those 90 pins. there's only so many ways you can split them up and even if you took those 90 pins and split them in to 10 control pins and 10 independent 8-bit busses you still need to put the switching fabric on each and every device you plug into the bus, including the motherboard. It's a waste. Not to mention if some device wants to use all 10 busses to transfer something doubleplusfast, every other device must wait. In a cell-oriented serial architecture that doesn't happen. Can't happen if properly done.
You're correct in stating that you can do it with a parallel bus but I don't feel it's as flexible as a serial bus.
As far as time-lagged goes, if you designed it correctly (a la ATM) you could implement a Class of Service to the entire subsystem. And if your two wires just weren't pushing enough data, you can parallelize them then.
No, the real thing to worry about isn't so much untrustable drivers as untrustable hardware. What happens when your network bus is your keyboard bus is your hard drive bus is your memory bus? Answer: You've suddenly got lots and lots of meaningless, inconsequential hardware on the same bus as mission critical, highly secured equipment. Imagine a rootmouse that, upon being plugged in, was able to query the harddrive for the contents of
This is significant. I believe this is the exact reason why they're taking a very hard and critical look at security on what they're proposing. Personally I think it's great. The idea of security and even encryption should be placed in Layer 1 or Layer 2 on the OSI network model, not up higher commonly sits.
I'm glad they're looking at the benefits of an open protocol as well. They hit the nail on the head with their statement about closed source drawing attention just because it's a challenge.
Your idea of a rootmouse is intriguing. How would one make sure that devices couldn't access parts it wasn't supposed to? Perhaps a seperate bus for critical system components, still allowing you to place everything on one but without the security? Perhaps a Bus Administration Unit which components must authenticate against to get access to other devices?