The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
some cache x-over discussion http://www.garlic.com/~lynn/2008c.html#78 CPU time differences for the same job http://www.garlic.com/~lynn/2008c.html#80 Random thoughts in general cache size and cache implementation can affect effective mip rate. there are some number of benchmark applications on the web that attempts to profile and characterize those details. variability concurrent activity, other application executing as well as possible interrupt rates ... can also affect cache hit/miss ratios ... and therefor effective mip thruput ... which, in turns affects measured cpu use. there is also "capture" ratio issues ... which can also affect measured cpu use. recent post/thread on the subject: http://www.garlic.com/~lynn/2008.html#42 Inaccurate CPU% reported by RMF and TMON there are a lot of common/similar technology issues with dealing with various kinds of caches (virtual memory, database caches, hardware caches, etc). for other topic drift regarding effective thruput with regard to database caches in a loosely-coupled environment ... we looked at this when we were doing scaleup ... old email http://www.garlic.com/~lynn/lhwemail.html#medusa and old post http://www.garlic.com/~lynn/95.html#13 when we were doing ha/cmp http://www.garlic.com/~lynn/subtopic.html#hacmp a lot of dbms caches have been the equivalent of hardware "store-thru" caches ... both the log and the main dbms being updated about the same time. some of the dbms implementations did an optimization analogous to "store-into" caches ... sometimes referred to as fast-commit; aka as soon as the log entry was written, the transaction was treated as committed, ... the associated datatbase records writes would be delayed ... being combined with large number of other record writes for optimization of disk arm motion. Also subsequent changes to the same record ... prior to their writes ... would effectively combine multiple changes into smaller number of writes. The problem was that these "fast-commit" strategies would be negated when working in a loosely-coupled environment. If a transaction came in on a (loosely-coupled) processor ... different from a processor which had a "changed" record ... not yet written to disk ... before the related locks could be obtained ... all such changed records would first have to be written to their "home" dbms disk location. As part of doing scale-up work for ha/cmp "distributed lock manager" ... also worked out being able to do any direct cache-to-cache copies ... piggy-backed with granting lock (in a store-into, fast commit, dbms environment). some of the processor cache implementations had implemented cache-to-cache copies (on miss) ... say, some of the numa hardware (aka we had participated in SCI meetings and consulted with some of the vendors that did NUMA SCI implementations, included one later bought by your favorite mainframe vendor) ... but they didn't have to worry about dbms failure recovery. This can get really tricky attempting to correctly merge logs and do transaction log redo ... in a loosely-coupled environment with multiple independent logs. at the time, we originally worked it out, most of the dbms implementations were still rather dubious that it could work correctly under all possible failure scenarios. random past posts mentioning sci: http://www.garlic.com/~lynn/96.html#8 Why Do Mainframes Exist ??? http://www.garlic.com/~lynn/96.html#25 SGI O2 and Origin system announcements http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP? http://www.garlic.com/~lynn/2001b.html#39 John Mashey's greatest hits http://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast http://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query http://www.garlic.com/~lynn/2001j.html#12 OT - Internet Explorer V6.0 http://www.garlic.com/~lynn/2001j.html#17 I hate Compaq http://www.garlic.com/~lynn/2001l.html#16 Disappointed http://www.garlic.com/~lynn/2002g.html#10 "Soul of a New Machine" Computer? http://www.garlic.com/~lynn/2002h.html#78 Q: Is there any interest for vintage Byte Magazines from 1983 http://www.garlic.com/~lynn/2002i.html#83 HONE http://www.garlic.com/~lynn/2002j.html#45 M$ SMP and old time IBM's LCMP http://www.garlic.com/~lynn/2002l.html#52 Itanium2 performance data from SGI http://www.garlic.com/~lynn/2003.html#0 Clustering ( was Re: Interconnect speeds ) http://www.garlic.com/~lynn/2003.html#6 vax6k.openecs.org rebirth http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out http://www.garlic.com/~lynn/2003p.html#30 Not A Survey Question http://www.garlic.com/~lynn/2004.html#1 Saturation Design Point http://www.garlic.com/~lynn/2004d.html#6 Memory Affinity http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE)) http://www.garlic.com/~lynn/2005.html#50 something like a CTC on a PC http://www.garlic.com/~lynn/2005d.html#20 shared memory programming on distributed memory model? http://www.garlic.com/~lynn/2005e.html#12 Device and channel http://www.garlic.com/~lynn/2005e.html#19 Device and channel http://www.garlic.com/~lynn/2005f.html#18 Is Supercomputing Possible? http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new? http://www.garlic.com/~lynn/2005j.html#13 Performance and Capacity Planning http://www.garlic.com/~lynn/2005k.html#28 IBM/Watson autobiography--thoughts on? http://www.garlic.com/~lynn/2005m.html#46 IBM's mini computers--lack thereof http://www.garlic.com/~lynn/2005m.html#55 54 Processors? http://www.garlic.com/~lynn/2005n.html#4 54 Processors? http://www.garlic.com/~lynn/2005n.html#6 Cache coherency protocols: Write-update versus write-invalidate http://www.garlic.com/~lynn/2005n.html#37 What was new&important in computer architecture 10 years ago ? http://www.garlic.com/~lynn/2005n.html#38 What was new&important in computer architecture 10 years ago ? http://www.garlic.com/~lynn/2005r.html#43 Numa-Q Information http://www.garlic.com/~lynn/2005v.html#0 DMV systems? http://www.garlic.com/~lynn/2006b.html#14 Expanded Storage http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces http://www.garlic.com/~lynn/2006c.html#7 IBM 610 workstation computer http://www.garlic.com/~lynn/2006c.html#40 IBM 610 workstation computer http://www.garlic.com/~lynn/2006c.html#41 IBM 610 workstation computer http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons http://www.garlic.com/~lynn/2006m.html#52 TCP/IP and connecting z to alternate platforms http://www.garlic.com/~lynn/2006p.html#46 "25th Anniversary of the Personal Computer" http://www.garlic.com/~lynn/2006p.html#55 PowerPC or PARISC? http://www.garlic.com/~lynn/2006q.html#8 Is no one reading the article? http://www.garlic.com/~lynn/2006q.html#9 Is no one reading the article? http://www.garlic.com/~lynn/2006q.html#24 "25th Anniversary of the Personal Computer" http://www.garlic.com/~lynn/2006u.html#33 Assembler question http://www.garlic.com/~lynn/2006w.html#2 IBM sues maker of Intel-based Mainframe clones http://www.garlic.com/~lynn/2006x.html#11 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006y.html#38 Wanted: info on old Unisys boxen http://www.garlic.com/~lynn/2007g.html#3 University rank of Computer Architecture http://www.garlic.com/~lynn/2007i.html#78 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#55 Scholars needed to build a computer history bibliography http://www.garlic.com/~lynn/2007m.html#13 Is Parallel Programming Just Too Hard? http://www.garlic.com/~lynn/2007m.html#72 The Development of the Vital IBM PC in Spite of the Corporate Culture of IBM ---------------------------------------------------------------------- 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
