The following replies lead me to not nfs mount any directories,
to not use nis+, and to run the applications locally, just exporting
the display over the isdn line.
This has helped tremendously!
Ellen
emarch@pinole1.com
Thanks for all the great help from the following people
(their responses are included):
David Schiffrin <daves@adnc.com>
I do lots of ISDN, and there are a few "hot spots"
you mention.
first, NFS is pretty intensive, and yes, mounting
across the ISDN link will be pretty slow. You can
allevieate some of those by using 'cachefs' on the
remote machines.
second, Xwindows can be net intensive, especially if
it is very graphic-oriented work. You don't say what
sort of X apps you are running over the link, but
there are some workarounds. There are Xservers, and
Xclient shared libs which can compress the X data
before it gets sent to the server. There are also
compressing routers which can sometimes help here
(they're less effective with graphics than text)
You also don't say how these ISDN connections to
your lan are made. There are some problems with
using a stock Sparcstation to serve them, as well
as specific tweaks for different ISDN access servers.
If you'd like to get more specific, email me with
some more details, and I'll try to help more.
+++++++++++++++++++++++++++++++++++++++++++++++++++
David M. Davisson" <davisson@emuni.com>
I would configure your telecommuters to not automount NIS+
directories to their local machine, but run them as X-terms only.
Launching applications through ISDN as an x-term can be slow, but not
as slow as you are describing. Speed of loading applications will
vary according to the app.
+++++++++++++++++++++++++++++++++++++++++++++++++++
mjb@liffe.com
Running the applications by starting them up over an ISDN line, is a slow
way of doing it.
I feel you should separate a distinction between OS, X Windows, Applications
and Data. Once these have been clearly defined, I would suggest only
transferring the data over the ISDN line.
You should separate a completely different subnet specifically for home
support users to have to connect through. The subnet, should have a filtering
system, which removes any unwanted packet types on it, so as not to detract
from performance. On this subnet, you should have
a number of powerful X clients (your user at home, starts up X in broadcast
mode, or direct mode, to connect to an xclient. This should spawn a dialup
as soon as the ISDN line detects the first packet. The X windows can then
be started from an x client, where the user can log on (as though they
were local to that xclient).
Applications that are then started up, are displayed over XDMCP, but is
actually executing on the host at your company site. This removes any
need from automounting, mounting data/applications ove the ISDN, and only
leaves one protocol actually communicating over the ISDN line.
This is my preferred way of doing it. If you'd like to talk to me about
this, contact me on 00441713792745 (0171 379 2745) (UK).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Andy Paton <apaton@wtl1.demon.co.uk>
I would look at Cachefs which is built into Solaris 2.x and avaiable
for Windows/win95/NT (PC-CacheFS).
Check out Sun Web server
http://www.sun.com/smcc/solaris-migration/tools/docs/courses/sysadminHTML/cachefs.html
Another good web address for info on cachefs
www.sun.com/sunworldonline/swol-08-1996/swol-08-sysadmin.html
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
baldma@aur.alcatel.com (Mark A. Baldwin)
At my previous job we went through this exact same scenario. We eventually
decided that ISDN was simply too slow to support remote NIS and NFS clients.
Any machines that we installed for telecommuting purposes had to have
local user accounts. They did not run NIS. No NFS mounts were allowed.
We installed Netscape locally for email access. And basically, the users
would telnet to an office machine, set their display back and run their
applications that way. They knew full well that graphics intensive
apps would perform poorly. Mostly they simply used xterms for writing
code and such.
As you mentioned, by having local user accounts and locally installed
software you run into other problems. Do you back up the machines?
What about configuration management? If the user has source code at
home and the machine crashes...
In the end we found that ISDN is simply too slow to allow for REAL
telecommuting. Our developers could work from home maybe half the time,
but certainly not full time. Until a faster technology becomes widely
available (like ADSL), you and your users will find telecommuting a less
than perfect solution.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Harvey Wamboldt <harvey@iotek.ns.ca>
I just did some quick math, and over a 128K ISDN line, it would take
about 64 seconds to do a complete screen redraw (1M 8-bit pixels).
This is what would happen if you run the app on one side of the ISDN
and display it (using X) on the other. After initial startup,
something like an editor might run at a reasonable speed. A graphics
package that works with large bitmaps would be hideously slow though.
If you are running the application directly on the home machine, then
something else is going on. Are you running cachefs? If you are, try
turning it off. Are you replicating a huge database? If so, try
running the client software on a machine on the same side of the ISDN
as the server. I'd have to agree with you. An hour startup time is
ridiculous. Does this startup time agree with the startup time on
your local LAN? If your local LAN is 10Mbps Ethernet, does startup
take about 100th the time when you are on the local LAN?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rnf@spitfire.tbird.com (Rick Fincher)
Set up the home machines essentially as X-terminals. You can even use Macs or
Windows machines with X software we do this over 28.8 modems.
Have the users rlogin to the work machines and set their DISPLAY environment
variable to the home machine. Then the application runs on the work machine and
all its files are read and written at work and don't use ISDN bandwidth. The
only things going over the ISDN line are the screen updates.
We use the following script in our .cshrc files to set the DISPLAY variable to
whatever machine we rlogin to back to the system where we are located.
You also have to run xhost on the local machine to allow the X-Window from the
remote machine to be displayed locally. You can use "xhost +" to allow all
remote X-Windows to run.
This script is for the C shell if you use ksh you'll have to modify it for k
shell syntax.
-----------------
# Set X screen destination
set var1 = `who am i | grep ")" | sed -e 's/^.*(//' -e 's/\..*$//' -e
's/).*$//'`
if ( $var1 != "") then
if ( $var1 != ":0" ) then
setenv DISPLAY "${var1}:0.0"
else
setenv DISPLAY :0.0
endif
endif
echo 'Display set to ' $DISPLAY
-----------------------
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Richard Skelton <rich@brake.demon.co.uk>
There are 2 things you could try:-
1) use cache-fs
2) run the X application on a remote hosts(only display on the local machine)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Berube, Rick" <reberube@tva.gov>
We use the Caching File System (CFS) to front-end NFS-shared CDROMs.
That way we only take the hit of actually reading the CD one time per
file/directory. The methodology of using a cfs for an imported NFS
could be equally as useful for a client host on a slow (relatively) link
such as IDSN. There's a white paper on SunSolve about using CFS. One
of its examples (I think) is expressly about using cfs for exporting
automounted home directories.