[Info-vax] OT: when is parallel not parallel?

[John Wallace]

On Aug 20, 6:46 pm, b... at server2.cs.uofs.edu (Bill Gunshannon) wrote:
> In article <bbeba56c-759c-4614-b1e0-5015f7098... at z28g2000vbl.googlegroups.com>,
>         John Wallace <johnwalla... 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
> billg... at cs.scranton.edu |  and a sheep voting on what's for dinner.
> University of Scranton   |
> Scranton, Pennsylvania   |         #include <std.disclaimer.h>  

"I often wondered why paralell technology wasn't brought to bear on
the dial-up modem issue"
Well it all depends on what you mean by parallel. If you mean lots of
wires sharing a strobe, that's likely gone forever. However, if you
mean one wire with lots of parallel datastreams on it, that's been
trendy for a few years in various incarnations, a high volume one of
which is the G.DMT ADSL signal - turn a phone line into a long
distance LW/MW radio transmission cable, split the signal into as many
"parallel" 4kHz channels as have a usable SNR, and get as many bits
per second as possible (depending on SNR) into each of the 4kHz
channels. Then reassemble it all back together at the far end to
reproduce the incoming single bitstream.

All facilitated by the joint miracles of DSP and nowadays usually ARM
(as in StrongARM), often combined with other stuff on a single chip.
And based on a genuine vendor independent industry standard
specification. Every DSL router is a minor miracle really. Any DSL
router you could buy today probably has more memory and compute power
than a VAX 7xx. If I knew enough about SIMH I'd even speculate on
whether some of the Linux-based ones might be capable of running
SIMH . I thought the lack of virtual memory might be a challenge, but
since someone's already done SIMH for the Sharp Zaurus ARM PDA [1] and
VMS on iPAQ has been mentioned occasionally here and elsewhere [2],
maybe it could be done for a decent SoHo router too. Because it's
there, that's why :-)

[1] http://brooknet.no-ip.com/~lex/public/zaurus/simh/
[2] http://brooknet.no-ip.com/~lex/public/OpenVMS_iPAQ/