[EMAIL PROTECTED] wrote:
Guess the next iteration was the 3380 D/E's and 3880-11's and 13's. Think the 11's made it to production but the 13's never did. Soon after(mid 80's)I left for greener pastures and walked into Amdahl hell with the 6880 ESP...and STK SSDs. Whew, I lived to tell about!
-11 and -13 were 8mbyte 3880 disk controller caches. -11/ironwood was 4kbyte record/page cache and -13/sheriff was full-track cache ... code name table in previous post http://www.garlic.com/~lynn/2007e.html#38 FBA rant the -21/-23 later increased the -11/-23 8mbyte cache size to 32mbytes. i got involved in some of the issues about how to optimize use of disk caches ... what they could and couldn't do. here is recent post discussing the -13/-23 track cache on how to interpret some of the original claims. http://www.garlic.com/~lynn/2007e.html#10 A way to speed up level 1 caches and a couple recent posts discussing/mentioning ironwood http://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller chache http://www.garlic.com/~lynn/2007c.html#12 Special characters in passwords was Re: RACF - Password rules there is reference to "duplicate" and "no duplicate" strategies ... given the size of 8mbyte ironwood "page" cache ... it wasn't impossible that when using ironwood for primarily paging activity ... that every page located in an ironwood cache (in typical configurations) was also duplicated in real processor memory (i.e. the aggregate size of processor real memories and typical aggregate ironwood caches were compareable). Given that the page was in real memory ... there would be no reason that the duplicate page in the ironwood cache would ever be used. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
