9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: john@csplan9.rit.edu
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Experiences with remote connections?
Date: Sat, 16 Jun 2007 03:11:21 -1000	[thread overview]
Message-ID: <6b567fa8c3318374c74025a988ccd4ef@csplan9.rit.edu> (raw)
In-Reply-To: <20070616185924.A99A41E8C4C@holo.morphisms.net>

>> When I read the papers, there's references to systems booting over the
>> network and even connecting via dialup. Now, I'm on cable here, and
>> unless VMware's NAT system and Qemu's -net nic -net user options
>> really suck (do they?), I just can't see the feasibility of such a thing.
>> Can anyone else share experiences with connecting to Plan 9 from
>> hundreds/thousands of miles away with something other than
>> drawterm?
>
> plan 9 is not really intended to boot terminals
> off a file server hundreds of miles away unless
> you have a really fast connection.
>
> however, there are things you could do to
> improve your situation and see if they help.
>
> the main thing is to set up a partition for cfs(4)
> to use and then use it.  if you do this, then
> directory reads and stats and walks still go
> through to the server, but reads of cached files
> can be served locally (the qid from the walk
> response from the server lets cfs figure out
> whether its cache needs to be refreshed).
>
> to do this you need to make a partition for cfs
> to use and then set cfs=#S/sdC0/cache (or whatever)
> in your plan9.ini.  you also need to boot a terminal
> with cfs in /boot.  pcdisk does, pc does not.
>
> before you set up cfs you can test how well it
> might work by seeing how much this helps your
> lc time:
>
> 	ramfs -m /n/ram
> 	for(i in rc ls mc lc){
> 		cp /bin/$i /n/ram/$i
> 		bind /n/ram/$i /bin/$i
> 	}
> 	cd; time lc
>
> russ

ramfs seems to improve lc by about a second
or two. Still far from what I'd consider acceptable,
which is unfortunate; once a program is loaded,
it runs very nicely and responsively. Maybe it
would be more feasible simply to boot the terminal
from its own disk, then import my mailbox and
mount my fileserver to /n/csplan9 so I can access
my files.

If I could figure out how to make vncs work properly,
that might be an option. Right now, it just complains:
vncs: vncchal: needkey dom? proto=p9sk1 user?


John



  reply	other threads:[~2007-06-16 13:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-16 12:41 john
2007-06-16 18:59 ` Russ Cox
2007-06-16 13:11   ` john [this message]
2007-06-16 19:31     ` Russ Cox
2007-06-16 15:27       ` john
2007-06-16 19:42       ` andrey mirtchovski
2007-06-16 20:28         ` geoff
2007-06-16 22:12   ` Francisco J Ballesteros
2007-06-16 20:18 erik quanstrom

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=6b567fa8c3318374c74025a988ccd4ef@csplan9.rit.edu \
    --to=john@csplan9.rit.edu \
    --cc=9fans@cse.psu.edu \
    /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).