From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu, Ronald G Minnich <rminnich@lanl.gov>
Cc: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Re: Announcing the release of NetBSD 3.0
Date: Wed, 28 Dec 2005 21:21:04 -0600 [thread overview]
Message-ID: <20051229032104.059271B1D70@dexter-peak.quanstro.net> (raw)
In-Reply-To: <43B2A325.1080409@lanl.gov>
Ronald G Minnich <rminnich@lanl.gov> writes
|
| erik quanstrom wrote:
| > i was interested in one posting (i'm to lazy to re reread it and find the
| > reference) where you were multicasting or broadcasting a buffer to
| > n nodes for digestion using what sounded like page-based DSM.
|
| available in ZOUNDS. ZOUNDS was more like an "attach this chunk of your
| virtual memory to this network connection endpoint" than a real DSM. I
| never did coherency protocols anyway -- MESI on an ethernet? You gotta
| be kidding ...
there are lots of fancy things one can roll up as part of DSM. but thair
be dragons in coherency protocols.
|
| Anyways, ZOUNDS used IP multicast for this stuff, and we have found out
| that many switches choke and die on IP multicast, even today. A nice
| theory, killed by a brutal gang of facts.
if #nodes >> #switches you could try using your own software gw to
forward the multicast across bothersome hardware. i've never found
a switch (even the linksys on my desk) to fail with a 224.0.0.1 local
network broadcast.
| > deep in the system that you couldn't mix processor types in a cluster.
| > (who's to say what node you might have landed on.)
| >
|
| the encoding cluster I mentioned was pentium/freebsd and alpha/linux
| (64-bit). You can do this stuff, you just have to be careful.
you were savvy enough segregate the DSM data from stuff on the heap/stack.
in the system i was talking about, the operating system was DSM based and
would send pages around underneath the application. stack, heap, bss,
data segment, whatever.
lets assume that we can reliably reset the registers and pc from one architecture
to the next, the insurrmountable problem with this kind of system is it is impossible,
given a page of memory, tell which bytes are endian-dependent.
this kind of system would only make sense in an virtual machine environment.
i'm suprised that that was never part of the discussion.
- erik
next prev parent reply other threads:[~2005-12-29 3:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20051223180437.GA2661@colwyn.zhadum.org.uk>
2005-12-24 9:01 ` lucio
2005-12-24 10:11 ` Uriel
2005-12-25 12:54 ` Uriel
2005-12-25 20:16 ` erik quanstrom
2005-12-27 1:12 ` Ronald G. Minnich
2005-12-27 1:36 ` erik quanstrom
2005-12-28 14:37 ` Ronald G Minnich
2005-12-29 3:21 ` erik quanstrom [this message]
2005-12-25 23:11 ` Paul Lalonde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051229032104.059271B1D70@dexter-peak.quanstro.net \
--to=quanstro@quanstro.net \
--cc=9fans@cse.psu.edu \
--cc=rminnich@lanl.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).