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?
--
E_NOSIG
One not-so-nice thing about all this high speed local connectivity is that it worries the Copyright Mafia to no end. The MPAA and others already see people copying entire DVDs in the privacy of their own homes, and are proposing draconic control schemes (like 5C does for IEEE 1394 -- see http://www.dtcp.com/ -- in short: how would you like your TV to send a message to your cloned DVD player in order to disable it remotely??).
But fortunately, the same technology can also be used by sane people to implement flexible certificate-based link-level security. Using IPv6, for example, would automagically enable IP-sec, and there should be enough address space left there (~85%) to give manufacturers a way to do autoconfiguration...
Serial protocols are useful for anything long-range, but when you need to deliver data between few devices located in the same box, and have to do it fast, one wire instead of 64 means theoretically 64 times less bandwidth, and in relaity at least twice less, no matter what. Only when the length of the line is enough to cause distortion/desynchronization of the signals serial protocol becomes superior to parallel one, and even that isn't true in all cases.
Contrary to the popular belief, there indeed is no God.
Your Russian sucks so much, I have made a CRT using it.
Contrary to the popular belief, there indeed is no God.
I would agree with your assesment of the limitations listed above, but I would point out that what's changing is the definition of 'the box'. Lines are incresingly being blured between where the box ends and the network begins. Highspeed External I/O is proving to be a nesesity in this networked world of ours.
There was a time when a user was happy with just an isolated box. Then LAN funtionality became increasingly needed (got boxen without a NIC? no?).
Today, without massive conectitity, the 'puter will quickly become a doorstop of funtionality. That is why these new standards make logical sence for today, and into the near future.
_________________________
I am not an Electrical Engineer, but I have a couple of friends who are. The problem with parallel buses, as stated in the article, is that signal degradation occurs when the signal paths get too long. The problem is that at bandwidths that will be needed in the future, the bus must be either 128-512 bit parallel, or must run at extremely fast speeds. The problem with being massively parallel is that the bus is now physically very wide, it is difficult to build and difficult for the 1st bit and the 512nd bit to be set at the same time. Running at higher speeds means shorter paths before degradation occours. The PCI spec is right about a 15cm bus length before repeaters now, increasing the speed significantly will lower this to the order of centimeters, not long enough for a peripheral or I/O bus, but fine for a memory or CPU bus, which is what the article said.
A wealthy eccentric who marches to the beat of a different drum. But you may call me "Noodle Noggin."
Quando Omni Flunkus Moritati
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.
Well put!
Especially the middle rant from Richard Heritage. It's just stupid.
_________________________
Most consumers simply could care less, even if you managed to explain the issues to them.
That's true while things are being implemented, but just wait till some hax0r manages to disable everyone's TV during the super bowl! Blood pressure will rise, then water pressure will drop, then the switchboards will melt down as millions call for product support.
It's not that consumers don't get irritated by these things, it's just that you have to get a critical mass all irritated at once. Then it becomes anger.
Parallel signals must be synchronized. Any difference in path length or loading results in the edges not lining up - known as skew. For example, Rambus PCB routing is approaching impossible due to the need to keep each trace the same length, keep the impedance constant, and avoid crosstalk.
Serial signals can self-clock. The receiver can lock on, decode the bits, and send them through a FIFO to reconcile the send and receive clocks. This does cost latency, though.
In other words, it's easier to make a single pin wiggle 8 times faster than to keep the edges lined up on 8 pins. Since pins are the bottlenecks in IC packages and circuit boards, it's also cheaper.
I think the article is centering on the memory bus in the computer, and not so much an external bus.
:)
They clearly talk about multiple slots, power supply issues, the classses being storage, network, video, and cluster, and so on. It is obviously about external buses and not system memory. Indeed, there is a discussion about how to connect the serial buses to system memory.
Admit it: You didn't read the article.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Parallel is great for integrated buses, where you're going to try to have a bunch of fast devices share those "64" lines.
But, if you can get some really fast serial connections that only use a wire or two apiece, this can simplify the individual circuits.
And as the serial connections operate in an asynchronous manner, "bursting" goes away, and the system is liable to cope more gracefully with diverse kinds of "traffic."
Would I rather have:
- A 64 bit SUPER-SCSI channel that can burst data across at 64GB/s, at those few moments when I'm trying to do so, and which more typically only handles 8GB/s because there's not a disk drive that can keep up.
- 32 independent channels providing 1GB bandwidth apiece, from which I can get a sustained load of 24 GB/s?
I think I'd rather have the latter, even though it has lower "burst speed."If you're not part of the solution, you're part of the precipitate.
Now, as a user of a portable PC, the power benefits of USB do tend to get reduced, since the main device may well be running on batteries anyway. Also, the wireless connectivity of Bluetooth is incredibly useful - and the Bluetooth technology is very low power. So, I'm not saying one is always better than the other, but I am saying that USB's place might well be when you're going to need a cable for power, since you might as well use one that delivers data too...
[USB is] just too slow. Firewire is better but... I think ethernet would have been a better peripheral bus choice. Ethernet doesn't supply power, does it? One big advantage of USB is providing power to low-power devices.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Why NOT reduce the CPU to a dozen pins?
Power distribution.
Is that all? Then take the power and ground in through the top of the chip. There's a big powered fan sitting there anyway, it would be nothing new.
Life's a bitch but somebody's gotta do it.
personally, having a mouse that could access my hard drive would really piss me off. I'm not sure what to think about replacing parallel buses with serial. Having a bow that was a giant serial network might be cheap and speedy but what happens when people figure out how to circumvent software privacy controls and read all your keystrokes or control devices directly? I think if you were going to move to a serial system that each component set should have a private serial connection ie. processor to RAM, and also have a connection to the rest of the system. That way all private connections remain isolated. Right now my DMA devices can communicate directly with the RAM and likewise the RAM to the DMA device but the DMA device can't sit back and watch what is going on between my CPU and RAM because there is a memory controller between the two. You COULD have like firewall chips in front of certain system resources but wouldnt those add as much cost to the system as the elimination of parallel controllers deducted? I like serial connections for hardware devices like hard disks and the like, because the commands/information and whatnot have termination I can connect them while they are in the middle of an operation and not have the system wonder where the hell it went. Firewire and USB are two great examples of this in effect. I'm not so sure I'd like my internal devices like the CPU and RAM on the same serial link with the mouse and keyboard though.
I'm a loner Dottie, a Rebel.