Re: OT: Steve Wozniak
- From: John Wallace <johnwallace4@xxxxxxxxxxx>
- Date: Wed, 19 Aug 2009 16:16:56 -0700 (PDT)
On Aug 19, 9:17 pm, David J Dachtera <djesys...@xxxxxxxxxxxxxxxx>
wrote:
"Richard B. Gilbert" wrote:
David J Dachtera wrote:
Neil Rieck wrote:
I, along with 700 others, just had breakfast with Steve Wozniac at a
conference sponsored by Waterloo Ontario companies like RIM, Dalsa and
Open Text.
http://www.communitech.ca/en/
Boy, I thought I was an optimist but this guy's optimism is
overflowing and infectious. Why would you OpenVMS people care about
this? The Woz now works for a company called "fusion i/o"
http://www.fusionio.com/
and he mentioned that big companies, like HP and IBM, are using
"fusion i/o" solid-state storage technology to set new TPC transaction
records while beating fiber-connected storage arrays by 10 times or
more (and costing a whole lot less)
http://www.computerworld.com/s/article/9100218/HP_adding_solid_state_....
In their view, multi-core CPU processors will only get faster which
means that magnetic storage will continue to starve them of data. They
feel that solid-state storage will become the primary system memory
while hard disks will be relegated to doing off-system backups.
Now let's see if their vision comes to fruition.
Hhhmmm... Sounds like we're talking about a new storage interconnect as
well, something akin to the Memory Channel, as I think it was called, so
data would transfer at near memory-bus speeds.
Think about it - how else could clusters share storage?
Unless you're totally stuck in the UN*X shared-nothing paradigm,
cluster-wide access to storage is what makes the clustered world go
around.
Even with the current generation of storage arrays (the common misnomer
is "SAN"), the interconnect is still the limiting factor. Until FC
speeds get up into the same range as memory bus speeds, this will remain
true.
Almost makes me wonder if the current serial paradigm of FC might
someday give way to a "parallel" paradigm where you have eight or more
FC cables per FC link rather than just one, or perhaps eight (or more)
parallel bit channels running over a single FC cable.
There are sound technical reasons for preferring a serial interface to a
parallel interface. It's not easy to determine when all the bits in a
parallel interface have settled to their final values.
Transitions in the "strobe" signal should take care of that.
The wider the
parallel interface is, the more difficult it is to make it work.
Are we, perhaps, "stuck" in the paradigm of the "old" parallel interface
technology? As noted re: strobe, it should be simpler, not harder. If
its harder, the approach likely needs a re-think.
D.J.D.
There has been a re-think and this week's bus is serial(ish). The
paradigm for the last few years and the next few years, as exemplified
in Hypertransport (and the Intel equivalent, Quickpath) and in PCI
Express and various others less well known, is high speed serial
interfaces, arguably the modern successor to the Inmos Transputer's T-
Links. If one of these serial(ish) links on its own isn't fast enough,
you put multiples side by side (e.g. PCIe x1 to x16, etc).
One of the low level reasons for this change to serial transmission is
that the sender just sends a serial bitstream, and there is no
"strobe" as such, and no "settling time" to wait for, not as such
anyway. In actual fact each link is multiple bits side by side so in a
sense it is parallel, but the wires are not used for sequential words
of parallel data, they're used for multiple simultaneous serial data
streams. And to make it go faster you don't add more bits to one link,
you add extra links.
Or for a better explanation go to the horse's mouth:
Hypertransport whitepaper: http://www.hypertransport.org/docs/wp/25012A_HTWhite_Paper_v1.1.pdf
Quickpath whitepaper: http://www.intel.com/technology/quickpath/introduction.pdf
.
- Follow-Ups:
- Re: OT: Steve Wozniak
- From: Bill Gunshannon
- Re: OT: Steve Wozniak
- References:
- OT: Steve Wozniak
- From: Neil Rieck
- Re: OT: Steve Wozniak
- From: David J Dachtera
- Re: OT: Steve Wozniak
- From: Richard B. Gilbert
- Re: OT: Steve Wozniak
- From: David J Dachtera
- OT: Steve Wozniak
- Prev by Date: Re: Process memory settings
- Next by Date: Re: OT: HP Financials
- Previous by thread: Re: OT: Steve Wozniak
- Next by thread: Re: OT: Steve Wozniak
- Index(es):
Relevant Pages
|