9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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


  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).