guy@auspex.auspex.com (Guy Harris) (05/26/90)
>Programming is a human activity. PostScript is a computer language >unsuited to programming. As Mike O'Dell pointed out, this is considerably less relevant to NeFS than to NeWS, since: >People should never write PostScript, ...people don't generally write NeFS programs, NeFS client code writes NeFS programs.
bin@primate.wisc.edu (Brain in Neutral) (05/26/90)
From article <1990May24.205149.6065@Neon.Stanford.EDU>, by pallas@Neon.Stanford.EDU (Joe Pallas): > In article <3378@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) > writes: >>What exactly is the complaint being made about PostScript here? > > Programming is a human activity. PostScript is a computer language > unsuited to programming. It was designed as a device-independent 2-d > graphics representation language, of which it is a nearly adequate > instance. Human programming is a human activity. Programming in general is not, as many programs also write programs. If you mean PostScript is a computer language unsuited for use by human in programming, well, ok. But it's a language that's easy for programs to generate, which may well mean it's a good language for program programming. Paul DuBois Internet: dubois@primate.wisc.edu UUCP: rhesus!dubois FAX: 608/263-4031
pallas@Neon.Stanford.EDU (Joe Pallas) (05/26/90)
In article <3385@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >...people don't generally write NeFS programs, NeFS client code writes >NeFS programs. I've never written any NeFS client code, so maybe I'm talking through my hat, but I doubt that NeFS client code is likely to write NeFS programs. NeFS client code is likely to ship NeFS programs over to the server once (at initialization), and then invoke those programs with the appropriate arguments as desired. Now you may call those invocations programs, but they're really just RPCs. The server-side programs being invoked by those RPCs will almost certainly by written by humans. Anyone with experience writing NeFS (or NeWS) clients is welcome to contradict me. (Use of PostScript as a compiler target language does not count.) joe
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/26/90)
In article <136212@sun.Eng.Sun.COM>, pugs@whitsun.Sun.COM (Tom Lyon) writes: > > My belief is that PostScript makes a pretty good intermediate language - we > just haven't figured out what the high level language should look like. Could you comment about the use of PostScript in file systems in view of Sun's experience with PostScript in window managers, setting asside the marketing issues with respect to X? I am making the obvious inference that Sun must view NeWS as a disaster, if only because of the amount of code that is being put down the memory hole. Could you say why NeWS and NeFS will have differing fates, despite the evident parallels between X vs. NeWS and NFS or AFS vs. NeFS? History (simplistic, one-sided history for third parties): -Sun announces a new, open standard for window managers, using PostScript, -Silicon Graphics receives presentations from Sun, and is impressed by the same arguements about sending programs instead of data. -SGI hears presentations from Getty's et al about X. -Since high speed graphics prefer programs to pixels and raster ops, SGI is less impressed by X than by NeWS. -SGI decides to join the Sun NeWS bandwagon. -after enormous porting, debugging, and re-writing effort and pain, NeWS becames the default window manager on Silicon Graphics IRIS's. -the same never seems to happen at Sun (the default, I wouldn't know about the pain). -X wins in the market, for various reasons. -Sun supports X vigorously and completely forgets NeWS. Summary: The idea is interesting. The implementation, particularly using PostScript, is less compelling for technical and business reasons. Disclaimer: NeWS will be the default in the next SGI release. Please do not understand anything here as an announcement--that's not my department. Moral: Avoid cute, mixed-case acronyms. Vernon Schryver vjs@sgi.com
amanda@mermaid.intercon.com (Amanda Walker) (05/26/90)
In article <1990May25.234950.1465@Neon.Stanford.EDU>, pallas@Neon.Stanford.EDU (Joe Pallas) writes: > Now you may call those invocations programs, but they're really just RPCs. Yes and no. They are RPCs in the sense that any client/server transaction is an RPC, but the important difference between NeWS & NeFS and, say, X & NFS is that the RPC is defined by the client, on the fly, to suit the client's needs, not defined in advance by someone who has to try and figure out what clients will want. Let me take a presently hypothetical example: a file service client for my favorite machine, the Apple Macintosh. The biggest problem with doing this under NFS is that, despite a reasonable correspondence between the file systems themselves, the *operations* performable on a file system vary quite a bit between the Mac OS and NFS, thus requiring a ridiculous amount of either network traffic or client-side caching in order to get acceptable performance. With NeFS, the client can blort over some code that tells the server how to implement those operations that the client is going to want to invoke. Flexibility wins. This is probably even more true for file service than for display service... $.02,-- Amanda Walker, InterCon Systems Corporation -- "Go not to the elves for counsel, for they will say both no and yes." --J.R.R. Tolkien, The Lord of the Rings
amanda@mermaid.intercon.com (Amanda Walker) (05/26/90)
OK. I've just FTP'd over the NeFS draft spec, and I am impressed. When I read the spec for NFS v2 (and XDR and RPC), my principal reaction was something along the lines of "Bleah--at least it seems to work, but I'm glad I don't have to deal with it." After reading through the NeFS draft, my principal reaction is, "OK, how long until they finalize it so that people can implement it?" NeFS gets my vote. -- Amanda Walker, InterCon Systems Corporation -- "Go not to the elves for counsel, for they will say both no and yes." --J.R.R. Tolkien, The Lord of the Rings
droms@sol.bucknell.edu (Ralph E. Droms) (05/26/90)
Can someone post a list of pointers to NeFS documentation and
references? Thanks...
--
- Ralph Droms Computer Science Department
droms@bucknell.edu 323 Dana Engineering
Bucknell University
(717) 524-1145 Lewisburg, PA 17837pallas@Neon.Stanford.EDU (Joe Pallas) (05/27/90)
In article <265DFAD2.5818@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >They are RPCs in the sense that any client/server transaction >is an RPC, but the important difference between NeWS & NeFS and, say, X & >NFS is that the RPC is defined by the client, on the fly, to suit the >client's needs, not defined in advance by someone who has to try and figure >out what clients will want. We have no disagreement here. My point is that, for Amanda's presently-hypothetical Macintosh NeFS client, the code which gets dynamically loaded into the server to define the Mac-appropriate RPC interface (things like lookup_file_ignoring_case, e.g.) will be written by humans, not programs. NeFS clients don't write code, they invoke code written by NeFS client implementors. And filesystem code will be even more complicated than graphics code, which is hard enough for humans to read and write in PostScript. joe
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/28/90)
In article <265DFAD2.5818@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > Flexibility wins. This is probably even more true for file service than > for display service... > Amanda Walker, InterCon Systems Corporation Yes, but only when all else is equal. Unfortunately, things are rarely equal. I've been thinking about why people have been saying the idea behind NeFS is good, that sending "programs" is better than sending requests. There seem to be two justifications for this claim. First is that high latency, high bandwidth networks do not like round trips. Second are varitions of the flexibility arguement. Concerning the first, I know of a Distribute Graphics Library that is required to look like a certain Graphics Library, on which applications in C, Fortran, Ada, etc. like to make >100,000/sec calls like "drawfoo(x,y,z,r)". This DGL library now runs at >20,000 "remote procedure calls"/sec over ordinary ethernet. As far as the application program is concerned, it is simply linked with a different graphics library. There are not 40,000 ethernet packets/sec, but the details are irrelevant. The point is that at 20,000 "RPC's" second, an ethernet looks like a high latency network. Also, at 200,000 to 1,000,000 GL calls/sec, we don't have a lot of time for compiling requests. Yes, there is work on "higher level" stuff, but that is irrelevant for my point, that high latency is not antithetical to "RPC". The most common failing in systems' designs are expressions of the designer's inability to so say "no". Here the flexibililty argument is a good way for file system designers to avoid designing the file system, to avoid doing the hard thinking and making the hard choices in caching, naming, locking, and so on. In practice, it seems all agree that humans will not write PostScript requests, that something will be compiling from something else. It is clear to me that for at least a few years we will not have the CPU cycles for file system clients to be doing the equivalent of SQL query optimization at a rate of one compilation of request to Postscript per file open-access-close, or even of one compilation per human interaction. It is more likely that there are a modest number of requests that any and all applications will ever make of remote, high latency file systems, and that these requests will be written and compiled exactly once, like rpcgen/XDR/etc of old. Rather than using a Turing-complete language like PostScript for a finite number of requests, a good designer would design a good, extendable (not extensible) protocol for the job. I designed and implemented a fancy WISIWYG, extensible, oject oriented, device independent, text preparation system, complete with internal description language for extensibilty for my employer-before-last. It was a mistake since the number of people interested and able to use the language was insignificant. It did allow quicker implementation, but that had nothing to do with having J. Random Oem, let alone T.Arb.User, use the language. The same will apply to NeFS. It is almost true of NeWS. PostScript is a good page description description language. Perhaps it will be a good file system language, when the relative latency of the network to the CPU is like that between troff/CPU and Apple Laserwriter, a lot worse than 50 MIPS vs. 30 msec, and more like printings' 5 MIPS vs. 5 sec. Vernon Schryver vjs@sgi.com
thinman@cup.portal.com (Lance C Norskog) (05/29/90)
It seems to me that the problem of sending a machine-independent program to a target machine for execution is intimately tied in with the problem of distributing application software in a machine-independent format. What OSF terms ANDF, or Architecture-Neutral Distribution Format. The quickest road to success is to hack GNU CC and C++ to compile to an ASN.1 format pseudo-assembler (called MIX, see Knuth's 3-volume opus) and ship that over the network, and on distribution tapes. The more high-level this MIX language (probably an object-oriented stack language) the faster compilation will be, and an interpreter/debugger will give a very nice development environment. The interpreter would include a full POSIX library, with optional run-time checking. Lance Norskog Sales Engineer Streamlined Networks
liam@cs.qmw.ac.uk (William Roberts) (05/29/90)
In <265DFAD2.5818@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >Let me take a presently hypothetical example: a file service client for >my favorite machine, the Apple Macintosh. The biggest problem with doing >this under NFS is that, despite a reasonable correspondence between the file >systems themselves, the *operations* performable on a file system vary quite >a bit between the Mac OS and NFS, thus requiring a ridiculous amount of either >network traffic or client-side caching in order to get acceptable performance. >With NeFS, the client can blort over some code that tells the server how >to implement those operations that the client is going to want to invoke. >Flexibility wins. This is probably even more true for file service than >for display service... The NeFS spec is quite clearly written as a slight generalisation over supporting a couple of slightly non-UNIX file systems. It doesn't go anywhere near supporting significantly different systems such as the Macintosh ("You mean each file has two parts, plus comments?") even though the polymorphic nature of PostScript would make it easy to allow things like arrays or dictionaries of filehandles rather than just single ones to be returned from open (for example). Flexibility is good, but NeFS seems to me to be all wrong. It dismisses the low-level network stuff with some hand waving, and it just feels like an insane way to go about something which needs to provide very high performance. I loved PostScript and was very fond of NeWS until it needed bigger machinery that I have available: NeFS just doesn't gell at all. I suggest we forget NeFS immediately and look at some real work addressing real problems: anyone who hasn't read the Coda paper should look out a copy Coda: A Highly Available File System for a Distributed Environment M. Satyanarayanan, J.J. Kistler et al IEEE Transactions on Computers, 39(4), 447-459, April 1990 Did anyone notice how little connection there was between the list of "problems with NFS" and the proposed solution? -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)
amanda@mermaid.intercon.com (Amanda Walker) (05/29/90)
In article <1990May26.213221.15248@Neon.Stanford.EDU>, pallas@Neon.Stanford.EDU (Joe Pallas) writes: > And filesystem code will be even more complicated than graphics code, > which is hard enough for humans to read and write in PostScript. Depends on the human, I guess :-). I don't see how writing file system client code in C (even with RPCGEN) is any easier, though... -- Amanda Walker, InterCon Systems Corporation -- "Go not to the elves for counsel, for they will say both no and yes." --J.R.R. Tolkien, The Lord of the Rings
brent@terra.Eng.Sun.COM (Brent Callaghan) (05/30/90)
In article <2284@sequent.cs.qmw.ac.uk>, liam@cs.qmw.ac.uk (William Roberts) writes: > The NeFS spec is quite clearly written as a slight > generalisation over supporting a couple of slightly non-UNIX > file systems. It doesn't go anywhere near supporting > significantly different systems such as the Macintosh ("You > mean each file has two parts, plus comments?") even though the > polymorphic nature of PostScript would make it easy to allow > things like arrays or dictionaries of filehandles rather than > just single ones to be returned from open (for example). The NeFS protocol goes a long way toward making Mac implementations more efficient. File attributes are represented as a dictionary - name/value pairs. The resource and finder forks of a Mac file could be represented as attributes of the data fork. Alternatively, if the server is not a Mac server and is not capable of supporting arbitrary attributes - we can fall back on Applesingle or AppleDouble representations. Either way, the protocol allows a Mac client to construct a single NeFS request to do what it wants. Consider the NFS requests required of a Mac client: to open a folder on the Mac desktop requires a READDIR to enumerate the files, then a LOOKUP on *each* name to obtain its attributes, followed by a READ on some of the files to get the icon. > Flexibility is good, but NeFS seems to me to be all wrong. It > dismisses the low-level network stuff with some hand waving, The draft spec for NeFS is deliberately vague about "low-level network stuff". There's nothing to be gained by spelling out in detail what transport is going to convey requests between client and server at this stage in the design. Currently, the prototype is built on RPC/XDR like NFS because that's what we know best. Eventually there will be a document that defines the protocol as expressed by RPC/XDR. > and it just feels like an insane way to go about something > which needs to provide very high performance. Why insane ? If we're talking client or server CPU there isn't really a lot of difference between NFS and NeFS. The client just transmits "canned" requests - these do not have to be generated on the fly. Existing NFS servers already employ an "interpreter" of sorts: the server currently executes one "operation" per request as defined by the NFS procedure number. The NeFS protocol just allows the client to string a bunch of operations together. The overhead in executing these operations is extremely small; it's just tiny drops of glue between vastly more expensive I/O operations. Remember: the drops of glue have the potential to eliminate hugely expensive over-the-wire operations. -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051
mo@messy.bellcore.com (Michael O'Dell) (05/30/90)
What might well be called "Clark's Law" is that "As bandwidth goes to infinity, latency becomes a constant 30 milliseconds." This is the round-trip delay across the US on a 1 gigabit or faster fibre-optic network. You can't change that number unless you change the speed of light, so there is NOTHING you can do about latency except avoid round trips!!! The fact that some application can successfully beat the life out of a local ethernet cable is NOT a feature when considering *networks which scale with latency*, and in Clark's view, and mine, them's the future of networking. Everthing else is essentially a multiprocessor by comparison. -Mike
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/30/90)
In article <23707@bellcore.bellcore.com>, mo@messy.bellcore.com (Michael O'Dell) writes: > What might well be called "Clark's Law" is that "As bandwidth > goes to infinity, latency becomes a constant 30 milliseconds." > This is the round-trip delay across the US on a 1 gigabit or faster > fibre-optic network. You can't change that number unless you > change the speed of light, so there is NOTHING you can do about > latency except avoid round trips!!! > > The fact that some application can successfully beat the life out > of a local ethernet cable is NOT a feature when considering > *networks which scale with latency*, and in Clark's view, > and mine, them's the future of networking. Everthing else > is essentially a multiprocessor by comparison. > -Mike I am apologize for not being clear. I claim doing 20,000 "RPC's" per second over ethernet (i.e. 50 microsecond/call) is in some sense equivalent to doing a more familiar number (500/sec?) over a "high latency" medium such as cross-country fiber. In neither case is there time for one round trip per call. One round trip/call at 20,000 calls/sec comes out to 25 usec/packet. Isn't the minimum packet time, including preamble, something like 60.8 usec on 10MHz ethernet? Instead of remote-file-system-programming-languages, some cheating seems more to the point. Obviously, to get 20,000 "RPC's"/sec, not to mention the 1,000,000/sec that we would like, it was necessary to cheat. Obviously, you can't let the application, whether it is the upper layers of the file system or a graphics application, catch you cheating. You can get impressive preformance gains many places by cheating. The Sun use of the directory bit for client cache control is effective chicanery. The Silicon Graphics "private" NFS mount option is, IMH(&biased)O, even better. Some of the newer network file systems show signs of the right kind of cheating. Please note that 30 msec latency is not very bad. It permits >=15 round trips/second. An NFS rsize/wsize of 64K would in principle give 1MB/sec of data thru NFS, 5-10 times most current NFS implements. The big deal with GByte (not Gbit) fiber is not the latency, but the bandwidth*latency product. Having MBytes in flight stresses lots of interesting things. Vernon Schryver vjs@sgi.com
jbvb@ftp.COM (James Van Bokkelen) (05/31/90)
In article <265DFDA9.58A5@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > After reading through the NeFS draft, my principal reaction is, "OK, how > long until they finalize it so that people can implement it?" I read the draft of 12-Feb-90, and saw various levels of precision (file size of 64 bits, time resolution to the nanosecond) that might be looked on as overkill, but they stuck with 32 bits (unsigned, this time) of seconds since 1-Jan-1970 as the low-resolution component of the time format. One or two more bits would probably suffice for everything except interstellar probes and nuclear waste dump monitoring systems, but I wouldn't design anything of this potential scope to expire in 2106 CE. -- James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
brent@terra.Eng.Sun.COM (Brent Callaghan) (05/31/90)
In article <1015@ftp.COM>, jbvb@ftp.COM (James Van Bokkelen) writes: > I read the draft of 12-Feb-90, and saw various levels of precision > (file size of 64 bits, time resolution to the nanosecond) that might > be looked on as overkill, but they stuck with 32 bits (unsigned, this > time) of seconds since 1-Jan-1970 as the low-resolution component of > the time format. One or two more bits would probably suffice for > everything except interstellar probes and nuclear waste dump > monitoring systems, but I wouldn't design anything of this potential > scope to expire in 2106 CE. Nanosecond resolution is required by Svr4. I don't know of any server that currently requires this resolution - but you never know... I'd be very happy if this protocol outlives me - let alone my grandchildren. Perhaps by 2106 we will almost be converted over to OSI protocols :-) -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051