[Info-vax] OT: Steve Wozniak

[Bill Gunshannon]

In article <bbeba56c-759c-4614-b1e0-5015f70983e7 at z28g2000vbl.googlegroups.com>,
	John Wallace <johnwallace4 at yahoo.co.uk> writes:
> On Aug 19, 9:17 pm, David J Dachtera <djesys... at spam.comcast.net>
> 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

I find it really funny to see the paralell interface discussed again
after all this time.  In the past, I often wondered why paralell
technology wasn't brought to bear on the dial-up modem issue.  Imagine
the speeds that could have been accomplished if one was pushing 8, 16
or even 32 bits simultaneously.  And the state of the DSP art has made
this doable probably a decade if not two ago.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>