Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!lll-tis!ohlone!lll-winken!csustan!csun!aeusesef From: aeusesef@csun.UUCP Newsgroups: comp.arch,comp.os.misc Subject: Re: Unix File System Performance Message-ID: <752@csun.UUCP> Date: Wed, 16-Sep-87 14:41:30 EDT Article-I.D.: csun.752 Posted: Wed Sep 16 14:41:30 1987 Date-Received: Sat, 19-Sep-87 09:17:10 EDT References: <1384@faline.bellcore.com> <7327@felix.UUCP> Reply-To: aeusesef@csun.UUCP (Sean Eric Fagan) Distribution: world Organization: California State University, Northridge Lines: 74 Keywords: Cyber CDC throughput Xref: utgpu comp.arch:2085 comp.os.misc:176 In article <7327@felix.UUCP> martin@felix.UUCP (Martin McKendry) writes: >In article <1384@faline.bellcore.com> hammond@faline.UUCP (Rich A. Hammond) writes: >>In article I wrote: >>> ... A >>>very high proportion of programs today are I/O bound -- a proportion >>>that will increase as we get faster processors. It seems to me that >>>filesystem performance is the next big area for competition. After >>>all, that's what makes a mainframe a mainframe, right? >> >>About 98% of the programs run on our systems use <2 secs of 780 CPU time, >>nor do they use very much I/O. There are only a few I/O or CPU hogs. >>Where do you get the idea that a high proportion are I/O bound? >> >(some stuff about programs and cpu load) One of the I/O hogs happens to be the operating system itself (or do you only support 1 user and 1 taks?). The example I'm always being given (and have started to give myslef 8-)) is a Cyber. A Cyber 170/760 is a FAST machine (8-10 M{I,FLO}PS [yeah, they're pretty much the same]), which also happens to have *VERY* fast I/O (on the order of megawords a second, I forget just how many). (It does this by having a seperate I/O processor, which handles all i/o: the cpu just tells it what it wants.) There is also a Cyber 180/830, also a very fast machine. It, however, gets only 1 M{I,FLO}PS (they added microcode 8-(). Therefore, it gets about the same instruction speed as a VAX (more or less, I won't quibble too much). However, it can support, nicely, about 30 or 40 users (moderately nicely; it starts to slow down at about 10 to 15), whereas a VAX (this is a 780 equivalent machine, more or less) dies at that many. Reason? Jobs rolling in and out of memory use up a lot of i/o bandwidth. >Based on simulation >results and real benchmarks, we found that you could make changes >by large factors (2-5) in either direction in CPU performance >without seeing anything like the same change in throughput (total >time to run benchmark). Like a factor of 4 or 5 faster in CPU >for only a factor of 2 change in throughput. Idle time on the faster >CPU goes up as expected. This on batch processing >with no terminal I/O. If that's not I/O bound, I don't know what is. >>(some stuff about large memories) (32M large? I use 96 myself...) >>If the system were smart >>enough to use all of memory as disk buffer rather than 10% of it, I'm >>certain that my stuff would just stay in core. Unfortuneately, there's two problems: 1) Processes tend to use this memory themselves, for code/data. Sure, you can swap (demand paged vm), but that doesn't seem much more efficient than just using the memory to hold the code. 2) That data has to be written to disk SOMETIME. I think I would rather put up with slow I/O than to have to worry about the machine corrupting my data. This can be cured if you have large memory AND a seperate I/O processor (buffer, while the CPU is busy, have the iop write the data), but I'm not too sure that that is done too often. >> >(some stuff about large number of users/data transfers) >>I'll agree that file system performance could be improved, but I'm >>inclined to believe that improving the use of main memory as buffers >>would be a bigger general win than any changes to the disk layout. This Cyber I'm talking about (830) has roughly 16Mbytes of main memory. It tends to use the memory to store jobs, and it gets better performance that way then our 760 (with an equivelant load [5 or 6 times as many users]) which can only have 256KWords and has to roll jobs into/outof memory. >> >What if I am planning to do both, and the incremental costs are worth it? >>Rich Hammond Bell Communications Research hammond@bellcore.com >Martin S. McKendry; FileNet Corp; {hplabs,trwrb}!felix!martin >Strictly my opinion; all of it The Cybers are 20+ years old; Cray had the right idea when he designed them. (But I HATE NOS!) ----- Sean Eric Fagan Office of Computing/Communications Resources (213) 852 5742 Suite 2600 1GTLSEF@CALSTATE.BITNET 5670 Wilshire Boulevard Los Angeles, CA 90036 {litvax, rdlvax, psivax, hplabs, ihnp4}!csun!aeusesef