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

[Rich Jordan]

On Aug 20, 1:23 pm, John Wallace <johnwalla... at yahoo.co.uk> wrote:
> 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/

A stack of DSl modems running SIMH under Linux would be a lot more
compact and less power hungry than a blade server chassis with
equivalent number of blades too...