Path: utzoo!mnetor!tmsoft!itcyyz!yrloc!rbe From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) Newsgroups: comp.arch Subject: Re: File and other disk caches Message-ID: <1991Feb8.210703.28222@yrloc.ipsa.reuter.COM> Date: 8 Feb 91 21:07:03 GMT References: <1991Feb02.202123.7744@iecc.cambridge.ma.us> <80@shasta.Stanford.EDU> Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) Organization: I P Sharp Associates, Toronto Lines: 41 I don't think any of the /370 channels I have seen have been water-cooled. The CPUs proper and cache, vector facility, are typically water-cooled, but I can't recall seeing any coolant tubes on 308x or 3090-class machines. They don't run that fast -- maximum transfer rate on most of them is either 3e6 bytes/sec or 4.5 bytes/sec. They also tend to overrun on tight data chaining (scatter-read, gather-write type operations to dasd, for example), which doesn't say much for their speed. When I was working at I.P. Sharp on SHARP APL, we gave up on data chaining in mid-record because of the inability of the /370 channel to keep up with things. Chaining in an interrecord gap was OK because you had about 100 or so byte times to fetch the next channel command word(CCW). This technique effectively stopped working in the mid-1970's when ibm announced the 370/145. Still, the system does hum right along: We had sites with concurrent user load in excess of 1200, offering trivial response time of about .1 seconds - this on a general-purpose, interpretive APL system! Now, whoever was it that was saying that compiler writers (interpreter writers are a related breed) don't know how to exploit hardware? Bob Bernecky Snake Island Research Inc. ps: I see that the origin of all this was something about disk caches. A few other points: a. IBM dasd controllers cache in the controller, which is connected to the cpu by that dinky 3 mbyte/sec pipe. The main advantage of dasd cache is reduced seek and rollaround delays. If you are reading a lot of data at once, the cache advantage becomes minimal. If you're reading 80 bytes(ibm still believes in card images...) off a 50kbyte track, then the cache will help a lot. b. The access methods allow cacheing sort of, sometimes, if you're a sequential access fan, by letting you specify the number of buffers for that file. No more than 255 buffers, please. 2 is the default. Non-sequential files probably don't cache, but I never used those access methods anyway -- for performance, we rolled our own command chains.