Re: The use of the term PCI-X on this list
Jonathan Fosburgh wrote:
> On Saturday 12 March 2005 08:23 pm, Hiten Pandya wrote:
>
>
>> PCI-X is different from PCI Express; the latter is also refered
>> to as PCI-e.
>>
>> -Hiten
>
> I know, and I prefer to call pci express pci-e, but I have read pci-e referred
> to as pci-x. It may be incorrect, but apparently not unheard of.
Current copies of the (many) PCI specifications are available to
PCI-SIG members for download. An imperfect, but still useful
overview is more publically posted here;
http://www.interfacebus.com/Design_Connector_PCI_X.html
There are many more 'potential' implementations than have yet
shipped, and quite a number shipping for 'industrial' SBC use
that few folks commonly see.
Max 'all out' data rates have not (yet), AFAIK, been implemented
outside of the lab, so there is still room to grow.
But - of importance to DragonFlyBSD - faster PCI(n)
*may not ever ship*.
'Soon Now' our peripherals, video subsystems, and storage
can be expected to be entirely on fast serial copper or fiber
optics. MB 'slots' - dropping each year in number -
may go away entirely for the majority of systems.
SATA-2, USB-2, Firewire-800, 10G E and FC-AL
are just the beginning. Serial copper now, serial fiber later.
It will soon also become much cheaper to put optical channels
right on the CPU die (Transputer with 'eyes' concept) - or nearly
so - than to do a complex MB. Look at package pin count and
the cost of lead bonding alone.
"Lightbridge" replaces North/South bridge scenario is coming
even to commodity 'PeeCee' markets - basic economics.
- Matthew & DragonFly team pursuit of liteweight messaging
fits perfectly with that eventuality.
Components may be quite a distance apart, and the DragonFly
model inherently handles latency and async events better than
most other models do.
We can safely leave the hardware 'off-list' and get on with the
job of just creating better code to USE it.
It will be there when we arrive! [1] ;-)
Bill Hacker
[1] Parts of this in use in telco switchgear for a *very* long
time. Note that features in Ericsson's 'Erlang' language were
for a real-world need for handling a shifting mix of distributed
resources in not-always deterministic time.
討論串 (同標題文章)
完整討論串 (本文為第 4 之 4 篇)：