wayne@ames.arpa (08/10/87)
While waiting at my diskless Sun workstation for a "cp" to complete,
an obvious question wandered into my otherwise empty head. When I do
"cp a b" on my workstation under NFS, what is in fact happening is
that disk blocks are being read on the server, forwarded over the
Ethernet to my workstation, processed briefly, sent back across the
Ethernet to the server, and finally written back to the same disk they
started from; a rather tortuous path at best. So I did a quick set of
timings on a 2.3 megabyte file: the local "cp" gave 0.0u, 4.0s, 1:26
elapsed. To get timings for running the "cp" directly on the server
(via "rsh") I timed both locally ("time rsh server cp a b") and
remotely ("rsh server time cp a b"); local was 0.0u, 0.3s, 0:21
elapsed and remote was 0.0u, 2.1s, 0:15 elapsed. I don't know how to
time the server's part of a local "cp", but looking at "perfmeter"
didn't show any significant difference in CPU usage. So in other
words, the time perceived by the workstation user went from 86 seconds
down to 21 seconds, with no apparent increase in server load! Given
this, has anybody taken the obvious step of automating this process,
sort of like having "cp" say "hmm, both these files are on the same
server and the file is big enough to cover startup time; I'll just
have him do the copy for me"? (I realize that "rcp" already does
something like this for "remote-to-remote" situations, but then NFS is
supposed to make things more transparent, right? And by the way,
"time rcp server:a server:b" gave 0.1u, 0.8s, 0:36 elapsed; not as
good as "rsh cp" but still a lot better than "cp"!)
Anyway, I realize this is the tip of a rather large iceberg (the "when
do you move the data to the computation and when do you move the
computation to the data?" question), and I have in fact been chipping
away at that iceberg myself (for example, I already have procedures
set up to do lengthy "find"s on the server itself). But I was just
curious if anybody has done anything "scientific" about this rather
limited version of the general question? Or UNscientific, for that
matter (like my proposed hacking of "cp" above). Sure seems like
something obvious to look at for (e.g.) SunOS.
Well, my "cp" is finally done, so back to work ...
Wayne Hathaway ultra!wayne@Ames.ARPA
Ultra Network Technologies
2140 Bering drive with a domain server:
San Jose, CA 95131 wayne@Ultra.COM
408-922-0100ron@topaz.rutgers.edu (Ron Natalie) (08/10/87)
One of the big advantages of NFS (or RFS for that matter) over past remote file system hacks is that it is (program wise) totally transparent to use the remote filesystems. You do not have to recompile or "know" specifically about whether you are doing a local or remote access. I'd avoid this. By the way, the fix that really needs to be done to the cp and rcp programs in this day of multiple access is to fix the silly code that tries to keep you from screwing yourself when you say "cp A B" when A and B are the same file. People feebly try to stat the inode and check internet addresses and all kinds of things to determine if the file is the same. There is no foolproof way to do this. I suggested that if the cp A B was not destructive when A and B are the same file, then you could do away with this check and the user gets precisely what he asked for without destroying anything. When I mentioned this to Doug Kingston, he figured out that if you do not "creat" over an existing file, but just read one and write the other and the "truncate" to the correct lenghth after you are done, you do not screw things. Unfortunately we thought of this too late to be on the 4.3 tapes (it is available on the BRL releases though). -Ron
mlandau@bbn.com (Matt Landau) (08/11/87)
In comp.unix.wizards (<8730@brl-adm.ARPA>), ultra!wayne@ames.arpa (Wayne Hathaway) writes: >While waiting at my diskless Sun workstation for a "cp" to complete, >an obvious question wandered into my otherwise empty head. [Describes the "cp" problem on diskless workstations: cp copies data over the net to your diskless host, then copies it right back to the server.] > So in other >words, the time perceived by the workstation user went from 86 seconds >down to 21 seconds, with no apparent increase in server load! It gets more interesting when you start talking about large compiles. Compiling the system I work on (on the order of a couple of hundred K lines of code, in a couple of hundred files, all on one server) from scratch my diskless 3/75 workstation takes around 2 hours. Compiling on the server takes only about a third as long. Needless to say, we've all taken to using "on server make" when we want compile the system! Another interesting number to think about is amount of traffic on the local ethernet. We did some back of the envelope calculations based on compiling all the sources and building all the libraries to generate our 3 megabyte binary. Taking into account all the various temp files and such that get used, we estimated that we move 30 to 50 megabytes of data across the network, none of which is necessary if the whole compile is done on the server. Given the usual load on the network around here, just moving that much data across the net eats up a significant amount of time! -- Matt Landau A rock feels no pain... mlandau@bbn.com ...and an island never cries.
lamaster@pioneer.arpa (Hugh LaMaster) (08/11/87)
In article <7779@slate.BBN.COM> mlandau@bbn.com (Matt Landau) writes: >In comp.unix.wizards (<8730@brl-adm.ARPA>), ultra!wayne@ames.arpa >(Wayne Hathaway) writes: >>While waiting at my diskless Sun workstation for a "cp" to complete, >>an obvious question wandered into my otherwise empty head. > >[Describes the "cp" problem on diskless workstations: cp copies > data over the net to your diskless host, then copies it right > back to the server.] > >It gets more interesting when you start talking about large compiles. (Discussion of more diskless workstation problems) > Matt Landau A rock feels no pain... > mlandau@bbn.com ...and an island never cries. Another approach to the diskless workstation (which I currently attribute to an employee of DEC) is to view it as a window server: You have enough horsepower in your diskless machine to run windowing, and then actually run your programs on other servers of various kinds, including the Sun servers mentioned, but maybe also a graphics server or a Cray. Diskless machines should be very effective window servers. If you want more local processing power to do local compiles, etc., you (probably according to my current guess) need a real local disk system. Otherwise, you are going to run into problems as described. But, to waffle a little, diskless configurations also may be a win if your primary usage is editing. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "IBM will have it soon" (Disclaimer: "All opinions solely the author's responsibility")
mlandau@bbn.com (Matt Landau) (08/11/87)
[I'm moving this thread of the discussion to comp.windows.misc, since that's where this is heading...] In comp.unix.wizards (<2473@ames.arpa>), lamaster@ames.UUCP (Hugh LaMaster) writes: > >Another approach to the diskless workstation (which I currently attribute to >an employee of DEC) is to view it as a window server: You have enough >horsepower in your diskless machine to run windowing, and then actually run >your programs on other servers of various kinds, including the Sun servers >mentioned, but maybe also a graphics server or a Cray. For some reason, I find the idea of viewing a Sun 3/75 with more than twice the raw horsepower of a VAX 11/780 as a simple window server amusing. On the other hand, I agree that low-cost window servers are going to be a big item in the future, serving basically the same purpose as ASCII terminals do now. However, that's going to require lower cost boxes and a network distributed window system that works -- both X and NeWS are in their infancy, and neither is yet quite ready to challange the world :-) -- Matt Landau A rock feels no pain... mlandau@bbn.com ...and an island never cries.
mash@mips.UUCP (John Mashey) (08/11/87)
In article <2473@ames.arpa> lamaster@ames.UUCP (Hugh LaMaster) writes: .... >Another approach to the diskless workstation (which I currently attribute to >an employee of DEC) is to view it as a window server: This is starting to sound like the BBN BitGraph, (BTL Blit / Teletype 5620 / ATT 630?), or osmeo f hte other graphics terminalstaht are starting to come in to existence that basically act as X-windows servers. This raises the itnersting issue: what are the tradeoffs between: a) diskless nodes + servers vs b) window-server terminals + (bigger?) servers in terms of: a) cost per seat b) ease of use c) overall response time d) General program-structuring issues. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
jas@llama.rtech.UUCP (Jim Shankland) (08/11/87)
In article <7779@slate.BBN.COM> mlandau@bbn.com (Matt Landau) writes: >... >It gets more interesting when you start talking about large compiles. >[Large compiles done on the diskless workstation take a long time, >because everything must be fetched and stored over the network.] >Needless to say, we've all taken to using "on server make" when we >want compile the system! >... >Given the usual load on the network around here, just moving that much >data across the net eats up a significant amount of time! On the other hand, if everyone starts running "on server make"s at the same time, the poor, perspiring server may be brought to its knees, while dozens of workstations sit largely idle. The problem is one of global resource allocation and load balancing, and hence hard to solve. This is why some of the OS research types are playing with dynamic process and data migration. Jim Shankland ..!ihnp4!cpsc6a!\ rtech!jas .!ucbvax!mtxinu!/
liam@cs.qmc.ac.uk (William Roberts) (09/03/87)
Expires: Distribution: >What are the tradeoffs between: > a) diskless nodes + servers > vs > b) window-server terminals + (bigger?) servers >in terms of: > a) cost per seat > b) ease of use > c) overall response time > d) General program-structuring issues. With a good window server, all of the detailed code for handling the physical device is in the window server process, NOT attached to every binary that might one day use the device. This has some effect on binaries for use with X (even though the X device independence stuff is an awful compromise), but the effects of using NeWS, with its high-level primitives and Turing-equivalent server, are staggering: A realistic program doing tricky segmented graphics and 2D animation has a binary of 737200 bytes when running under SunView, but running under NeWS, it reduced to 147450 bytes, i.e. to 20% of the original size! With diskless nodes, you need to pull BIG binaries across the network to handle your display. With window servers, you can have much smaller binaries, device independence etc. This suggests that you need the window server code resident in the diskless workstation, hence the idea of window-server terminal. The knock-on effect of smaller binaries is hard to judge - does it reduce the cost per seat by reducing the cost per server? -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-980 4811 ext 3900