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.
second :P
This architecture does not have to be faster than SBus and PCI initially, but it has to have the potential to increase its performance by ten times or more in the next four years.
_________________________
Jeez... soylent and then the alpha/omega bit... put the #@(*&#@ing Xenogears away already. =p
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?
Gigabit ethernet from system memory to the disk? Or to the NIC? Sounds like a bunch of highly specialized NCs in a single box.
Now if only they'd concentrate on this rather than the pointless MHz race we could actually see some real improvement in performance.
--
E_NOSIG
because IPV6 smokes current io protocols. Ethernet tunneling of IP inside of IP has been the most over prescribed solution to network woes for many years, now its time for a more daring approach, encapsulating IPV6 over a preexisting SLIP or X25 transmission... the future is ours ! behold the advent of wireless radio !
A noticed people are mention firewire, usb, and etc. I think the article is centering on the memory bus in the computer, and not so much an external bus. Of course, if they are considering moving the memory bus to a serial fashion, then it would be possible to simply place your digital camera straight on the memory bus, ignoring your usb connector. My guess is, however, by moving to a serial memory bus, it makes it easier to do multiprocessor processing, since you don't have to connect almost a hundren wires to another processor to share memory, timing signals, etc.
---
--
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...
It's just too slow. Firewire is better but... I think ethernet would have been a better peripheral bus choice. It's already a platform independent standard. Ethernet controllers have already shrunk to single chip solutions (10/100Base-T PCI cards for less than $10! So don't say it's expensive.) It works over MUCH longer distances than USB or Firewire or even (non-current loop) serial. There are already protocols for printing and file sharing in place that also cross platform, even network scanners. All that was needed was a standard for keyboards, mice, vid capture, etc. IMO, this is just the industry trying to cash in on a new, badly designed, proprietary "standard" rather than use better, cheaper stuff that's already out there.
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.
As we all know, processor speeds have been going through the roof year after year. I/O performance, on the other hand, has improved at a slower pace. Perhaps now we can look forward to an increased rate of I/O performance improvement.
By the way, Intel said that 2003 would be the earliest that a "cheap" version of the Itanium would be available, cheap enough for desktop or home use. Deerfield is the name of this home version of Itanium. 2003 is a long way off; perhaps that will give Compaq enough time to produce an equivalent Alpha.
This is one thing we all can THANK H4x0Rz and their ilk for keeping away. If the ability to "disable devices" exists, you can bet viruses/trojans will appear to exploit it. Vendors who's products were wrongfully disabled en masse will catch HELL from consumers. Fir this reason, "features" like this will never make it to the market. THANKS TO CRACKERS! Like it or not, admit it or not, the existance of crackers does help us all.... because without evil, can good still exist?
Um, sorry, no time for in-out I'm just here to check the meter!
hehe.
Your Russian sucks so muchE
It's not Russian. Does "Mehanicheskij Apel'sin" mean anything to you?
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
The Java crowd would love it. Finally they could do systems programming without having to grok pointers .. :-)
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
i'm singing in the rain...
thwack
just singing in the rain...
thwack
what a glorious feeling...
thwack, thwack
i'm happy again
dumbass.
This is undoubtably a gross oversimplification, but parallel communication systems must ensure that the signals from the many channels arrive synchronized, whereas serial systems get this for free. Maybe some EE's can provide a more rigorous explanation of this, or at least some good links.
Single mode fibre optics, where there is one and only one path along the fibre, can provide throughput which is not physically achievable by other means. C Novom Godom.
Good, open standards in IO (or just "standards" for that matter). You know what I've been waiting for since USB came along? Joysticks! That's right, I want to be able to hook up multiple controllers, map them to "virtual" joysticks or the keyboard, and select one or more of them for every game. No more plugging in and out of controllers and re-adjusting. I especially like the windows 95 joystick control panel: it lets you set up multiple joystick configurations, but... you can only use the topmost one! I now have a shareware applet to switch between different configuration but still... I hate MS! Sorry, just had to get that off my chest.
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
I was recently reading about bluetooth. A vast number of vendors are supporting its development. It has got a good speed also. (cant remember it right now).Bluetooth is a very viable technology for home users and the speed is sufficient for printers, scanners, keyboards, mouse etc devices.
I am not sure if firewire/usb can be useful for home users or for anyone else for that matter.
What do you fellas think?
CP
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.
From reading the article, it seems that the author
does not have a firm grasp of the concepts of computer architecture.
1) System I/O(SIO) was renamed to Infiniband in October.
from the article
"agreed to merge their technology initiative with the Compaq-led FIO (future I/O) group supported by Hewlett-Packard Co., IBM Corp., and others."
2) This was an IBM led effort.
3) I thought MCA had a top clock rate of 40MHz?
from the article:
"But PCIx, which is backward-compatible with existing PCI cards, does not provide balanced throughput and is otherwise saddled with the same
restrictions that existing PCI implementations have."
4) By utilizing multiple peer PCI busses(2 to 3 slots per bus) the I/O does indeed become balanced. The only major restriction is on overall PCI bus length which is not a major concern if all your devices are in the same box.
from the article:
"Parallel buses are also restricted in the number of system board slots allowed for connecting I/O adapters. Serial channels have no slots and are limited more by protocol design than by physical signal-transfer capabilities."
5) So this means all Infiniband busses are point-to-point or in a star configuration. Also, signal quality plays a huge role in the max capabilities of any bus, parallel or serial.
from the article:
"Most importantly, parallel I/O buses are a shared resource that implements some kind of prioritization scheme and interrupt processing that determines which controller is transferring data on the bus. In contrast, serial channel cables extend directly from the system without needing intermediary adapters, or interrupt processing, to establish communications between entities on the channel."
6) This may be true from an external sense but, in a serial channel system, you have just moved the location of all these activities. They still occur(inside the host controller) just not on an external bus.
from the article:
"The integration of network switching technology in the channel allows simultaneous multiple data transfers or commands in the channel. In other words, the aggregate transfer rate of a serial I/O channel can be several multiples of the single-link transfer"
7) Huh? How can you exceed the max transfer rate of the physical medium. If the author is writing about multiple delayed transactions improving efficiency of the bus I would agree. However, PCI and to a greater degree PCI-x, support multiple delayed transactions as well.
from the article:
"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.
"
8) Elimination of host adapters? I don't believe that elimination of host adapters was the intent of Infiniband. A complete system will always have to convert data from one format to another. I imagine Infiniband will be used to mainly cluster machines and to connect to remote I/O boxes that are full of... what... yes... PCI slots.
Also what new memory is the author talking about. Apparently he knows something that JEDIC doesn't.
from the article:
"How Much Data Can a Data Chip Chuck?"
9) This whole section was confusing. Most system performance will not be limited by the memory bandwith but by the processor bandwidth. Since most memory transactions are cacheable, the host controller must snoop the processor bus on a large portion of I/O transactions thus slowing things down. In order to get a significant speed up the operating system must mark I/O buffers as non-cacheable so snoops don't occur(ala AGP).
10) To get efficiency up the packet size must be pretty large. I would not expect the Infiniband protocol to follow any existing protocol. The overhead in current protocols is just too much to get effective MMIO performance.
11) Remember Infiniband is a server architecture. Don't expect it to get to your home PC in the next 7-10 years. PCI is more than plenty(and cheap) for a home or even workstation system.
12) Security: What IT wizard would even consider hooking up a user to his machine's memory subsystem? That's just silly.
Inifiniband is a breakthrough in PC system bus architecture providing low latency high speed connections to attached components. However I don't think it is the holy grail of computer architecture.
-Anonymous Coward
Well put!
Especially the middle rant from Richard Heritage. It's just stupid.
_________________________
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.
Compaq has had nearly 10 years to figure out how to popularize the Alpha, what makes you think they will get it right with another three?
So, history has finally decided that the C64 and the 1541 disk drive didn't talk too slowly after all...
They intend to make the CPU, storage, RAM just another connection to the (intra)net. The author briefly cogitates the subject of security.
How am I, the business user, going to implement security in Linux? You're on the third firewall model, ipfwadm -> ipchains -> iptables. How are us mortals going to keep up?
You're going to have to settle on a single model, then whack the shortcomings, a non-glory type of task.
Are you up to it?
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.
Transputer legacy
1394[a] or even USB[2]
Point-to-point vs eg daisy-chain requirements
Protocol stacks
Async vs isochronous sharing of links
Failure modes
Cache vs memory roles
DMA-hub-on-a-chip
A mobo would have to kick off the primal BIOS ROM-RAM transfer as part of the reset sequence for the serial i/o-RAM DMA, but everything from there could be controlled from the the BIOS thus loaded. Periph cards could have their BIOS contributions pulled in via a serial i/o DMA instead of cluttering the address space with their random-access ROMs.
ROMs for serial i/o access only could be made denser and cheaper, since data could be shifted out instead of accessed with much addressing gating.
This has been brought to you as yet another obvious techno-musing in the fight against progress-crippling patents ;-)
Are there any types of slotted cards now that would be unsuitable under the new form of architecture. What about graphics cards, for example?
Also, can all of the I/O ports that we currently have on the back of a PC be comfortably handled by this new architecture?
Then there's the discussion of impacts to case and motherboard designs assuming one removes the slots entirely. Power supply was mentioned, but are there any less obvious ones, such as drive bays?
Give me a break, they want us to give up 64Bit I/O transfers at 66Mhz (the article computes 264 Mega Bytes/second for PCI 2.1)... for a serial standard? This is 2.1 Gigabits/second folks.... and it's a heck of a lot easier to push this in parallel than it is to use specialized Gallium Arsenide components to try to spit it out a serial port. At the least we're talking about signals with a clock rate of 2 Ghz.
If you throw the "double clocking" trick on to PCI (seems fair to me), you get the amazing speed of almost a gigabyte/second! Where are we going to get 10Ghz network clocks? Why waste the effort, when it should be relatively easy to extend the 64x performance increase in Parallel bus design for a very long time into the future?
I'll tell you why... Intel, and others, want to keep the cost of entry high, and since there is no other way to do it, they are willing to have us pay for an unnecessary layer of hardware that only they can afford the research to create, to keep their market share!
I say no to this obvious attempt to raise the price of computing. We need to keep hardware prices falling in line with Moore's law, and not restrained in such a stupid manner. Serial may be fine for external interfaces, but parallel remains the only sane choice for a very long time to come.
In my opinion, this idea of making internal busses all serial is NUTS!
--Mike--
I (same as above) thought of this, so it must be obvious ;-)
Their steering committee members are listed via an animated .gif, as are the Sponsoring Member Companies.
I wonder if these high-price-of-entry clubs will go out of style when open source gets "world domination." I guess it does weed out the merely curious.
By the same token, I wish there were a way not to charge readers for *any* public official standard (IEEE, ISO, UTA, Unicode, you-name-it). After all, if readers are able to understand it, their attention time is a significant payment on their part, and the marginal cost of serving another electronic copy is near zero.
(Thank you W3C and IETF, for showing how to do it).
In your face!
PS - Attn. moderators: if you label this post as off-topic, redundant, flamebait or troll, I take no offence. After all, you're probably a fruit or mad that you'll never get laid.
PCI on the other hand doesn't have length descriptors, so unless a disconnect would be signalled by the initiator or target, the op would continue until a latency timer would fire and force a disconnect. The "backwards compatibility" with PCI is *only* used if all cards on the bus aren't PCIX.
"Split Completions" are a *really* nice feature of PCIX that cuts down on retries. (You send out a request for a read and the target comes back with the data "whenever.")
Oh well, I never expected that article to get things totally right..
If networking and I/O are to become increasingly difficult to tell apart (loosely from the article), will we also see a possible sharing of hardware devices across computers ? In todays officespace, there is a lot of redundancy going on, with machines and especially harddrive capacities of ridicolous prpotions to what they are actually used for (since certain software seems to be needing these and that specs).
If anyone could enlighten me on the aspect of using these serial "networking" I/O solutions to share resources based on external hardware, as well as a possible migrating I/O structure, that would be great. It seems this is a better solution than todays "exported network drive" system.
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.
Although this info is old news, I am supprised that no-one has picked up on the implications Infiniband should have on our purchasing decisions today. The nature of the spec (see: www.infinibandta.org - site should be complete by end of Jan 2000 with more details and the various reports referenced) means that in order to retain 'legacy' devices in the new architecture they will need to be I2O complient. The physical architecture of the 'chassis' and the new processor board size and specification will make PC boxes obsolete. The great advantage I see is the superb scalability inherrant in the few publically available details. The 'just slot in another processor board' may mean 'Work-station' to 'Beowulf' cluster in very quick order. I hope everything will be a lot clearer by Jan 31.
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.
Heh, Money said something without just quoting the article. :-)
Bluetooth is slow, too slow. Do not believe the marketing hype (ala microsoft). These are not the droids you're looking for...
.asp
You'll notice that speed is not mentioned on the blehh-tooth faq page: http://www.bluetooth.com/v2/faq/default
"The gross data rate is 1Mb/s." is what one finds after reading through the tech page: http://www.bluetooth.com/v2/docume nt/default.asp
For comparison: the airport cards apple manufactures run at 10Mb/s (and you can get one today).
That's too bad, the previous post is IMHO a very good post that should be moderated up.
There is a problem with the moderation system: I am never a moderator when I want, and when I am a moderator usually I rarely find something interesting to moderate...
Oh well.
which is surprising considering that Scalable Coherent Interface (SCI) is already standardized and available.
"Yeah well