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.
the implementation of external, non-shared, non-blocking
switched connections lower latency communications between multiple channel entities, particularly between systems in a cluster
dynamic system configuration and hot swapping virtual controllers implemented in software, eliminating many host adapters
smaller system dimensions due to the elimination of host adapters and the reduction in power and cooling requirements
new memory and memory controllers for connecting to the serial channel
an increase in the number of host-based storage and data-management applications
the blurring of the distinction between I/O and networking
_________________________
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?
OK, something is seriously, hardcore, balls-out to-the-mat bugging me about this article. It's as if two people wrote it--one with a clue(and an impressive amount of such at that--lots of very fascinating stuff embedded within this article!), and then, the one who went without.
;-)
/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.
I'm not kidding--I've actually never read an article that on certain levels provided a fascinating glimpse at things to come, but on others rang so wrong that I was left in shock.
Bottom line: Somebody's agenda is leaking. Lets look at the Parallel v. Serial chart:
Parallel I/O Bus Serial I/O Channel
Max Physical Bus Length 1 meter 10,000 meters
Conductors/Pins 90+ 4 to 8
Grantable.
Conductor Materials Copper Copper, fiber optic
What? You can't deploy a fiber solution with multiple cables? None exist?
Given the range on fiber cabling, a rather intriguing method of avoiding data interception is rotating your bits through the available transmission lines, then routing each line through a different path. Now, you could always have the same bit travel over the same cable, or you could use a pseudorandom algorithm with a shared secret seed(see spread spectrum), but you'd most assuredly have a parallel architecture that was fiber optically based.
Slots/Fanout 3 to 16 slots for adaptors Hundreds of channel addresses
Uhm, really? Serial doesn't necessarily possess hundreds of channel addresses any more than parallel must necessarily not be implemented over fiber lines. RS-232, HSSI, pretty much any serial standard outside of USB/Firewire/That funky serial PCI replacement that was hangin' around the last Linuxworld is strictly point to point.
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. 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. The sheer fact that you have more channels to deal with generally means that it's far, far simpler to design for(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?). But, there's no conspiracy going on here; the advantages one gets from ridiculous quantities of theoretical bandwidth and easier hardware development are rather offset by the advantages of flexible cabling, smaller devices(ever seen those minimodems that aren't even the full size of the slot?), and a blurring between internal and external interfaces. Lets not forget the ability to Kill The Beige Box
Power Supplied Yes No
Gee, small problem, you have twenty cards in your machine, now you have twenty more wires...anyway, this is ridiculous. They're pitching a specific implementation and calling it the architecture as a whole. You can power hard drives off of Firewire, which last I checked wasn't 90 pins in a fanned slot formation.
Addressing Scheme Physical address bus Network addressing
There's a mantra embedded in this that screwed USB rather royally for all sorts of reasons. Turned out USB provided no way to verify which instantiation of a device is which--in other words, if I plug two Super Nintendo controllers into a Super Nintendo, the console knows that the controller plugged into the "Player 1" slot is the 1st controller, and the controller plugged into the "Player 2" slot is the second controller.
You can't do that with USB--every time you boot up, the order randomly shifts. They were so keen on network centric addressing, and so loathe to demand addressing be physically built onto every single device, that they completely broke multiplayer gaming on the same system.
Again, a flaw with the implementation, not the overall architecture.
Total Bandwidth Single session, unidirectional Multiple session, bi-directional
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.
I'm not one to go ballistic--check my posts, this is rather out of character. But reading something like this pretty much just forces me to go a bit out of character and post the following, care of Richard Heritage, Circa 1995:
God is this [stupid]. I mean, this is rock-hard stupid. Dehydrated-rock-hard stupid. Stupid so stupid that it goes way beyond the stupid we know into a whole different dimension of stupid. It is trans-stupid stupid. Meta-stupid. It is stupid collapsed on itself so far that even the neutrons have collapsed. Stupid gotten so dense that no intellect can escape. Singularity stupid. It is a blazing mid-day sun on Mercury stupid. It emits more stupid in one second than our entire galaxy emits in a year. Quasar stupid. This has to be a troll. Nothing in our universe can really be this stupid. Unless this is some primordial fragment from the original big bang of stupid. Some pure essence of a stupid so uncontaminated by anything else as to be beyond the laws of physics that we know. I'm sorry. I can't go on.
That being said, lets take a look at the rest of the article, which appears to be quite good:
the blurring of the distinction between I/O and networking
This is significant. There's an artificial distinction between networking and system I/O, propogated by belief that all the essential components that a system requires should be held as physically close and as accessably fast as possible. As individual device speeds fail to scale in comparison with available bandwidth(how many megs a sec are we pulling off of hard drives nowadays...now how fast can UDMA66 go? How fast can PCI 2.1 go?), aggregation of large numbers of individual devices becomes the primary design goal. The difference between multiprocessor boxes and Beowulf style clusters will blur, as systems literally become able to blob together--individual cache space for local processing, but it will end up no slower accessing the hard drive of a neighbor than accessing your own.
(Incidentally--I did some experiments a while back with two computers having their external SCSI adapters connected, thus appearing to make a single CDROM show up on both machines. Fascinating stuff, but it's not usable--one computer would freeze as the other initiated SCSI connectivity to the CD drive. Of course, this was on a friend's pair of Windows machines...)
Without adapters full of hardware providing a barrier to access for incompetent or wayward coders, device-level hackers will have unprecedented access to system internals. Obviously, this is a technology direction that needs to take security very seriously.
Somebody's trying to sell hardware that provides a barrier to access against incompetent or wayward coders. What, are they saying that device driver writers right now can't embed trojans in a mouse driver that send data from sensitive blocks of the hard drive to a drop point on a remote network? Give me a break--device drivers have low level system access. There are schemes to address limiting a given driver to a given range, but the entire concept of a driver(the segment in kernelspace that directly interfaces with some hardware) bristles pretty harshly at the reality of being unable to issue calls to given hardware addresses.
Actually, a general design where a driver must declare what bus addresses it plans to use--and is then held to that by the operating system--is a pretty good way to prevent faulty drivers from taking down excessive amounts of hardware.
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
It'll be interesting to see what comes out of the whole SIO gambit. As long as it isn't utterly bungled by Firewire style licensing, it should be interesting.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
In particular I want to make sure that future I/O controllers handle scatter-loaded pages well - this means some sort of MMU/TLB type structure in the I/O interface (either a fully fledged page table walker or a unibus-adaptor style software managed mapper) - these always seem to get added on after the fact (for example AGP's GART that doesn't handle cache coherency well). The problem is that such an object isn't part of a bus interface protocol - it's part of an interface chip and it's going to be a different, complex register interface for every manufacturer - the manufacturers are going to provide drivers for WinXX - Linux (and other OSs) are going to have to write drivers for all of them - we need either a standard piece of hardware (register interface) or a BIOS flexible enough to be used by all potential client OSs.
On the OS side we need to be thinking ahead too - I'm also looking forward to seeing closed-box computers - they're going to get smaller and cheaper, there's no reason why I should have these monster computer boxes all over my room - what it costs to make an enclosure EMI proof is amazing - I want sealed ones - a whole bunch of little ones that I can plug new stuff in to upgrade - want a faster CPU - replace the old one - it's just a box with a CPU and memory - want more disk - buy a new box, drop it on the desk and plug it in (don't reboot - why would we want to do that), want to watch DVD? bring the TV from the other room, plug it in. We're starting to see some of this with USB - we're going to see more in the coming year with Bluetooth .... devices that appear while they are close to their hosts and disappear as they move away - I suspect that this technology is going to become ubiquitous for things like headsets, laptops, PDAs, maybe even printers.
Up untill now we've require people to shut off the power and open a box in order to stuff a card into a slot when we add new functionality to a computer - I think that in the future that will be the exception (maybe only for memory upgrades) rather than the rule.