🚀 go-pugleaf

In article <id.IO0W.TLE@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> [re the idea of pluggable buses]
|> [...]
|> 
|> I'd like to see the bus specifics decoupled from the software, so you had
|> some sort of interface that you told "go to unit so-and-so and send this
|> control/read this data". Then you could use a low-cost hookup with ethernet
|> type cables, or a high-speed bus type option, without impacting the software.
|> You could even plug a low-speed adaptor into a high speed bus to hook up
|> your laptop when you get home.
|> 
|> If course this would logically be a LAN (um, CAN: Computer Area Network?).

We have a project making this sort of thing here.  The network
technology is actually ATM, and the problem being addressed is that of
bus overload arising from very high incoming data rates from a gigabit
network - the data never actually touches a `bus', it goes direct to
the device it's for.

This is a big win in the case we're interested in, the multimedia
video stream (which can come direct from our ATM camera in one
workstation, over one of the ATM LANs we have, and thence to the ATM
framestore which we'll have real soon now (TM)).


But there are interesting other classes of research issue - for
example, if your processor is separated from its DRAM by an ATM
interconnect, how's about rescheduling when you get a secondary cache
miss?

And the name?  Well, it's not so much a computer-area as a desk-area:
it's called a DAN.
--
Robin (Campaign for Real Radio 3) Fairbairns       rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
"They had twelve years to lay in wait for us" - Bush supporter on Nov 4