Prev: NYC LOCAL: Wednesday 31 March 2010 NJLUG: Revolution OS Movie
Next: inetd problems
From: Joe Pfeiffer on 25 Mar 2010 00:39
Tim Roberts <timr(a)probo.com> writes:

> Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> wrote:
>
>>Tim Roberts <timr(a)probo.com> writes:
>>
>>> Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote:
>>>>
>>>>SMP was a new and interesting problem about twenty years ago.
>>>
>>> Twice that -- Seymour Cray was doing SMP with the CDC 6600 in 1964.
>>
>>6500 (two 6400 CPUs) or 6700 (not really symmetric; a 6400 and a 6600).
>
> All of the 6000s (and Cyber 70s and 170s) had either 10 or 20 peripheral
> processors, each of which was a full-fledged processor with both a small
> private memory and a shared view of central memory.

Good point, but not where the real computing work was done. And still
not symmetric (in spite of symmetric hardware), since the OS ran on PPU 0.

Also, of course, the PPUs were the earliest example (that I know of) of
a crude early approximation to hyperthreading, since they were really
ten sets of registers and a single CPU.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
From: David Given on 25 Mar 2010 20:48
On 22/03/10 12:43, Rainer Weikusat wrote:
[...]
> SMP was a new and interesting problem about twenty years ago.

A few years ago I worked for the now-defunct Tao, which made the Taos
and Elate operating systems. Their main claim to fame was portable
native binaries that could run on any architecture (the portable binary
format was translated to native machine code at load time).

This combined very nicely with another feature, which was ASMP. You
could construct clusters of machines of different architectures that
communicated via high (or low...) speed links. Processes and devices
could be started on any processor, and communicate invisibly.

It was great for development: when porting the OS to a new headless
board, we'd hook it up via a serial cable and cluster it with a version
of the OS on a host PC. Processes run on the dev board would have access
to the host PC's file system, tty, ethernet stack, etc. We could run a
shell on the host PC (for fast interactive access) and spawn processes
on the dev board; or cat stuff directly to the dev board's drivers; or
start a file system on it and mount it on the global VFS; etc.

At one point we had a demo of a PC with an 8-node transputer network,
all combined into a 9-node cluster. We'd run a Mandelbrot generator that
would do one scan-line per node. Unfortunately the relative speeds of
the devices meant that by the time each transputer had completed one
scanline, the PC had done all the rest...

Naturally, being interesting technology, nobody wanted it so it never
sold. Which is one of the reasons why Tao is now defunct and I work
elsewhere.

</nostalge>

What happened to OpenMosix? That was a really interesting system
supporting remote device drivers on Linux and live process migration,
allowing you to set up tightly-knit clusters which looked on the inside
like a single machine (no shared memory between processes running on
different nodes, but they could talk to each other by pipes, and the OS
could move them around as the load changed). I used it very successfully
for a small build farm, but then it kind of vanished.

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: NYC LOCAL: Wednesday 31 March 2010 NJLUG: Revolution OS Movie
Next: inetd problems