local and remote cpu resources and the acme model of interaction

local and remote cpu resources and the acme model of interaction

[Alberto]

In <199504241111.MAA08305@netlab.london.sco.com>
	Dave Edmondson <davided@sco.com> wrote:

> : > if i run it on the terminal, then i end up
> : > compiling there.
> : not if you type 'mk' in a window connnected to the cpu server.
> 
> this is the crux of my concern (at this point i should make it clear
> that i've never actually used acme or help or plan9).  i guess that if
> i can have typescript windows in acme, then i can have acme windows
> where whatever i type is interpreted by a process on the cpu server
> (start a typescript and then connect to the server).  then i can 'mk'
> there and see the output, and presumably click in the appropriate way
> to have acme find the files/lines/... as necessary.  what seems odd is
> that i have to start a typescript window and then connect to the cpu
> server.
> 

You do not need to start a window connected to the cpu
server in order to run something there. Just type 'cpu -c mk', and
It will do the job. So 'mk' is local and 'cpu -c mk' is remote.

local and remote cpu resources and the acme model of interaction

[serge]

>on a seperate note, thinking about how graphics might work in acme -
>what /dev/mouse, /dev/bitblt, ... do acme's clients see ?

Probably /dev/ocr will be sufficient.  :-)

>poisoned ones ?

Eh?

local and remote cpu resources and the acme model of interaction

[Matthew K]

Dave Edmondson wrote this...
> 
> this presumes that the terminal and cpu server share a common
> architecture.
DOH!! damn good point.. i told you i had obviously missed something..
woah but wait a second.. if data (ie data and bss) pages are stored in
a byte independant format is it still a problem, because the code
pages are taken from the namespace on the cpu server yes?? maybe bit
twiddling would be necessary to overcome the byte ordering problems.. 
but still it is a fairly major hurdle.

			Matt
-- 
#!/bin/sh
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D3F204445524F42snlbxq'|dc;exit
Matthew Keenan   Systems Programmer   Information Technology Division
      University of Technology     Sydney Australia

It's nice to be in a position where people apologize because they
assume there's humor in your work, based on past experience,
but they're not sure where it is. -- Rob Pike

local and remote cpu resources and the acme model of interaction

[Gary]

> 	- i have to manually choose to run it remotely,
yup

> 	- that's three words to type or select, not just one to click.
> i could solve the second by wrapping `mk' into `cpumk', and then
> adding `cpumk' to the tagline i suppose.

yup

> and while i'm here - how easy is it to use acme to debug graphical
> programs (like 8.5 or acme), given that it doesn't actually support
> graphics `inside' it's own interface ?

Use two windows.  One with acme and the debugger, the other with
the application you're debugging.  Same as with X et al.

local and remote cpu resources and the acme model of interaction

[Dave]

: So 'mk' is local and 'cpu -c mk' is remote.

this doesn't really address the issue, which is (i guess) twofold:
	- i have to manually choose to run it remotely,
	- that's three words to type or select, not just one to click.
i could solve the second by wrapping `mk' into `cpumk', and then
adding `cpumk' to the tagline i suppose.

on a seperate note, thinking about how graphics might work in acme -
what /dev/mouse, /dev/bitblt, ... do acme's clients see ?  poisoned
ones ?

and while i'm here - how easy is it to use acme to debug graphical
programs (like 8.5 or acme), given that it doesn't actually support
graphics `inside' it's own interface ?

local and remote cpu resources and the acme model of interaction

[Matthew K]

rob@plan9.att.com wrote this...
> 
> The real answer lies in further research.  We've started exploring the
> possibilities of more fine-grained distributatibilty, which would enable
> acme to have remote processes available, transparently, that could
> invoke all commands for it, yet keep all the symmetries.  Absent that,
> another possibility is a more ad hoc solution of starting explicit slaves
> across the network and communicating with them directly.  I've put
> that off in favor of, I hope, more help from the system itself.

i know this probably is an over simplification, but.. wouldnt it be
possible to just kill stop a process, make a copy of its address
space, copy that to a cpu server, and kill continue it? i would assume
this would be done when a process gives indications that it is cpu
intensive enough to warrant the move (this isnt that difficult to do).
text pages wold be apart of the namespace so that wouldnt need to be
copied, the only things needing copying would be any bss and data
pages. this would probably require another relocation of addresses
(difficult), or a re-doing of how addressing into data and bss pages
is done (ie all access would have to go through one extra level of
indeirection, just what you need for a performance hit). there are
probably alot of other considerations i havent even begun to
contemplate yet, this is more a stab in the dark, than a workable
solution.

			Matt
-- 
#!/bin/sh
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D3F204445524F42snlbxq'|dc;exit
Matthew Keenan   Systems Programmer   Information Technology Division
      University of Technology     Sydney Australia

It's nice to be in a position where people apologize because they
assume there's humor in your work, based on past experience,
but they're not sure where it is. -- Rob Pike

local and remote cpu resources and the acme model of interaction

[rob]

One of acme's failings is that it tends to concentrate the computing on
a single machine again.  At the cost of some broken symmetries, one can
create a window within acme, connect it to another machine, and run
commands there.  This is clearly inferior to having big things run remotely
automatically.  In fact, I usually run acme on the cpu server, which has the
(weaker) problem that mouse motion and so on is communicated across
the wire.  Even on an ISDN line, however, the responsiveness is still better
than, say, running an X terminal and sam over the same wire.

The real answer lies in further research.  We've started exploring the
possibilities of more fine-grained distributatibilty, which would enable
acme to have remote processes available, transparently, that could
invoke all commands for it, yet keep all the symmetries.  Absent that,
another possibility is a more ad hoc solution of starting explicit slaves
across the network and communicating with them directly.  I've put
that off in favor of, I hope, more help from the system itself.

All that said, I still use acme exclusively.  It's not perfect and it's hard
to learn because its rules are so different from the usual conventions,
but the investment in learning is repaid.

-rob

local and remote cpu resources and the acme model of interaction

[Dave]

: > if i run it on the terminal, then i end up
: > compiling there.
: not if you type 'mk' in a window connnected to the cpu server.

this is the crux of my concern (at this point i should make it clear
that i've never actually used acme or help or plan9).  i guess that if
i can have typescript windows in acme, then i can have acme windows
where whatever i type is interpreted by a process on the cpu server
(start a typescript and then connect to the server).  then i can 'mk'
there and see the output, and presumably click in the appropriate way
to have acme find the files/lines/... as necessary.  what seems odd is
that i have to start a typescript window and then connect to the cpu
server.

i have read that plan9 doesn't attempt to move jobs around for me (the
process distribution is coarse), but this seems to be an area where
things don't fit together wonderfully.

i would also add that this exact problem exists if you use emacs on a
`terminal' and wish to compile on a `cpu server' - you can't use the
default lisp support for compiling programs and wandering through the
errors.

local and remote cpu resources and the acme model of interaction

[Gary]

> where should acme be run ?

on the terminal

> if i run it on the terminal, then i end up
> compiling there.
not if you type 'mk' in a window connnected to the cpu server.
Similarly you could use acme for development on non-plan9
machines you're connected to.

>  if i run it on the cpu server, then the server is
> doing a lot of the little jobs that the terminal was so good at.
yup


> perhaps, given the rising power of the terminals, this is now a moot
> point - i would guess that an r4000 is capable of running the compiler
> when necessary (even if it only has a relatively slow connection to
> the fileserver), but then when would i use the cpu server ?  and,
> perhaps more importantly, how does it fit into acme's model of
> interaction ?

We've been asking similar questions at Basser.  We have Pentium 90
terminals, and our R3000 cpu server and the terminals have exactly the same
connection (ethernet) to the file server.  Previously the cpu server
was useful for RAM-intensive jobs (the plan9 linker seems to need ridiculous
amounts of it), but with 32M terminals, that's not a problem either :-)
I hardly ever use the cpu server.

Eventually we hope to get our two DEC alphas working as cpu server
and file server with a dedicated FDDI link.  Then it might be worth
the effort of going to the cpu server.  A multiprocessor cpu server
would be good also.

local and remote cpu resources and the acme model of interaction

[Dave]

something that i've been puzzling about over the weekend:  in the
original plan9 papers terminals are described as (my words) `a machine
which runs the window system and the editor'.  cpu servers are used
for compiling (and the like).  other people have noted that they run
mail notification programs on their terminals, and so it seems that
terminals are used to offload user interaction and possibly user
notification from the cpu servers, which are used for more
computationally intensive tasks.

now there is acme.  acme includes an editor, it is a window system,
and the mail component does notification.  if i hit `mk' in the right
place in acme it will (perhaps) cause the compiler to run.

where should acme be run ?  if i run it on the terminal, then i end up
compiling there.  if i run it on the cpu server, then the server is
doing a lot of the little jobs that the terminal was so good at.

perhaps, given the rising power of the terminals, this is now a moot
point - i would guess that an r4000 is capable of running the compiler
when necessary (even if it only has a relatively slow connection to
the fileserver), but then when would i use the cpu server ?  and,
perhaps more importantly, how does it fit into acme's model of
interaction ?

just the ramblings of an idle mind (whilst digging my garden as it
happens).

dave.