Re: [9fans] Experiences with remote connections?

Re: [9fans] Experiences with remote connections?

[erik quanstrom]

> cfs can be a problem for a programmer: compile/run/debug/compile
> cycles tend to be unfavourably long since everything has to be copied
> back to the server and then read again.

for this reason, god^wthe labs also gave us the cpu server.

- erik

Re: [9fans] Experiences with remote connections?

[Francisco J Ballesteros]

>
> plan 9 is not really intended to boot terminals
> off a file server hundreds of miles away unless
> you have a really fast connection.
>

I have been using two programs from the octopus,
oxport/ofs (in sources, contrib) as a

styx<---ofs----> op <----oxport---->  ns

gateway, it seems to work well when ping reports 120+ ms of rtt.
I use this to boot a locat inferno to work using our FS file tree and it
seems to work well. I think I copied the man pages along with the source
into sources.

Re: [9fans] Experiences with remote connections?

[geoff]

cfs should help a lot.  I usually work remotely by connecting with cpu
to a cpu server near the file server, and running rio in that window.
Opening windows in the rio on the cpu server quickly produces windows
in which one can compile, run and debug quite rapidly.  A local sam
usually suffices but `sam -r $cpu' may be faster for large files.

Re: [9fans] Experiences with remote connections?

[andrey mirtchovski]

cfs can be a problem for a programmer: compile/run/debug/compile
cycles tend to be unfavourably long since everything has to be copied
back to the server and then read again.

Re: [9fans] Experiences with remote connections?

[Russ Cox]

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

mc is accessing all sorts of odd files that i'd
forgotten about (it reads files in /lib/font to
figure out string widths to insert tabs correctly
to make the columns line up).  try just comparing
ls with and without the ramfs -- that should be
more representative of what cfs can do.

i've booted over a few hundred miles before
and also over an early cable modem (28.8k up
via phone line, 1M down via cable) and it was
okay once cfs got going.  the real test is to make
a cache partition and try cfs directly.

russ

Re: [9fans] Experiences with remote connections?

[Russ Cox]

> 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

Re: [9fans] Experiences with remote connections?

[john]

>> 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.
>
> mc is accessing all sorts of odd files that i'd
> forgotten about (it reads files in /lib/font to
> figure out string widths to insert tabs correctly
> to make the columns line up).  try just comparing
> ls with and without the ramfs -- that should be
> more representative of what cfs can do.
>
> i've booted over a few hundred miles before
> and also over an early cable modem (28.8k up
> via phone line, 1M down via cable) and it was
> okay once cfs got going.  the real test is to make
> a cache partition and try cfs directly.
>
> russ

I set up a 200 MB partition for cfs; it seems to be helping
a bit. rio on the cpu server works okay too. I'll just have
to see which I end up using more.
Thanks!


John

Re: [9fans] Experiences with remote connections?

[john]

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

[9fans] Experiences with remote connections?

[john]

So, with the terminal I've got set up here, it takes about twelve
seconds to execute 'lc' in my home directory. Although drawterm
is annoying and doesn't provide quite the same "Plan 9 experience",
I might have to switch back to it if I don't figure out how to improve
my setup.

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?

I'm thinking (hoping) the fault lies with VMware and Qemu's networking
setups, but I can't be sure. The best thing would be to find an old
laptop (I'm low on space), install Plan 9, and test it.

Thanks



John