NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/ibm/pc/hardware/35269

Text File | 1993-01-09 | 5.4 KB | 140 lines

Newsgroups: comp.sys.ibm.pc.hardware
Path: sparky!uunet!math.fu-berlin.de!news.th-darmstadt.de!adams
From: [e-mail] (Adams)
Subject: Re: PC Multiprocessors with Shared Memory
Sender: [e-mail] (The News System)
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of Tue, 5 Jan 1993 21: 56:56 GMT
Date: Sat, 9 Jan 1993 17:59:51 GMT
References: <[e-mail]>
Nntp-Posting-Host: pdv2.fmr.maschinenbau.th-darmstadt.de
Organization: TH-Darmstadt
Lines: 126

In article <[e-mail]> [e-mail] (Dawson Dean) writes:


>      I would like to connect several (2 to 4) PC's together through
>   shared memory. The goal is to get bus level speeds while transferring
>   blocks of data. I would probably be running some flavor of Unix on the
>   PC's. I have written and measured software on networked Sun's, and
>   network speeds are far too slow for what I want (on our local net,
>   we are finding around 10ms per 1024 byte UDP packet). I am trying to
>   find out if I can get faster speeds through a bus. A friend suggested
>   that I connect two disk controllers together to make an asynchronous channel;
>   plug one disk controller into each pc and a cable directly connects them
>   so instead of talking to a disk it talks to the other controller. Somebody
>   else suggested I try a similar trick but using video cards and processors
>   each use an unused part of video ram as a shared buffer.

>      All I need is an asynchronous communication channel (no clock sharing
>   or anything), that effectively allows me to do a fast read and write
>   blocks bewteen two PC's. Really, the shared memory would be used like a
>   very fast net. Currently, my software uses asynchronous UDP
>   packets, so I hope to just rewrite that low level stuff to handle asynch
>   packets through this shared bus buffer. I am not too worried about the
>   system software end, but what really worries me is the hardware so I am
>   looking for a solution that requires as little hardware as possible.
>   I want to build simple hardware and write a lot of software.

There exist two major approaches:

1) Using memory of PCs as shared memory.

    To let one PC (1) access the memory of the other (2) in a direct
    manner and vice versa, that means one PC becomes busmaster of the
    other. A part of address space of (1) would be mapped in
    a direct manner onto some memory of (2) and vice versa.

    This approach is reasonable simple, as only bus signals
    have to conditioned to be transferred over a distance.

    Most of the VME-Bus to ISA-Bus adaptors work this way
    and use ECL-level for transmission.

    Meilhaus Electronic, Munich,  showed

        PC-adaptor <--> Universal Adaptor <--> VME-Bus Adaptor.

    Any adaptor may be attached to the "Universal Adaptor",
    that means

        PC-Adaptor <--> Universal Adaptor <--> PC-Adaptor.

    should be possible.

    It should be a reasonable fast approach.

    DISADVANTAGES:
    --> Personal meaning <----

    A) As busmaster capability is required, (1) must claim bus from
    (2) and vice versa, there will occur conflicts with some
    other busmaster cards like SCSI- and Ethernet controllers.

    B) PC does not know bus arbitration. This allows the
    "alien" to claim the local bus for ever
    (No refresh today .....) and to crash the local system.

    C) Critical signals have to be carried over a long distance.

2) Using seperate shared memory with own control logic.

    This does not require busmastering and carrying critical
    signals a long way. As much as I remember, DEC did it this
    way to connect VAXen back-to-back.

    Indeed the adaptor  need not even be mapped into the memory address
    space of the PCs, if it is to be accessed in a FIFO like
    manner, as I would expect .

    Reading/Writing from /to a port would be suffiecient
    (REP INSW / OUTSW ).

    Hardware is pretty simple...
    AMD has some application notes using their state machines
    to design such FIFO-networks. It takes some
    drivers [244,245], an AMD29-154 and two DRAMS, up to 4Mbit.
    (Each connection about 100,-DM, 256kBytes buffer, and
    5Mbytes/s.)

    I think Xylinx has puplished a similar application note,
    using their FPGAs.

3) Using seperate communication processors like Transputers.

    Did you ever think about just to take transputer cards to
    interconnect PCs? This works for moderate performance
    well, if you do not mind the price.

    Guys next door run such setups.


>      Ideally, I want some mix of cables and cards to connect two PC's. Does
>   such a thing commercially exist? Can I go to a store and buy one? If not,
>   then I assume that this has been built by various people. Where can
>   I find out more about some of these implementations?
CERN, Geneva.

>  Is there a standard way to do this?
Upcoming standard will be SCI. BUT too fast for a PC.

>  Does anybody have any suggestions about connecting disk
> controllers together?
Will not work well. Connecting IDE-IDE you have to worry about
bus arbitration and cable length.!!!!

Connecting ST506 controllers back-to-back should never work.

>  Could I do something with a shared scsi bus? Can I
>   mate two scsi controller cards?
Though it should be possible, you have to worry about
-) controller ID [at least one controller can not longer occupy ID 7!],
-) connect-reconnect capability.

>   Dawson Dean
>   [e-mail]
best, adams