Mersenne Digest Sunday, July 9 2000 Volume 01 : Number 756 ---------------------------------------------------------------------- Date: Fri, 07 Jul 2000 03:20:49 -0700 From: Stefan Struiker <[EMAIL PROTECTED]> Subject: Mersenne: Compaq Presario 7998 Clock Oddity Hi All: On several Athlon machines, from 750MHz to 1000MHz, P95 takes about the same number of clocks per iteration doing a factoring assignment, in the present case 4.75 billion. The Compaq 7998 settles at 5.28 billion for the same task, but can be driven down to 4.75 briefly by re-booting, running ReCache, and then some start/stop/start shenanigans. Soon the number of clocks starts to drift upward, and settles at 5.28/5.3 again. Other trial factoring stages show the same anomaly: drift-and-settle always at a higher than expected number. Trying the Advanced/Time test on the default 10 mill exponent, I notice unusual variation: from .125 (expected) to .134 (dreadful) for a 1GHz machine. Any insights? Thanks And Best Wishes, Stefanovic _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 07 Jul 2000 10:08:14 -0500 From: David Underbakke <[EMAIL PROTECTED]> Subject: Re: Mersenne: Compaq Presario 7998 Clock Oddity The solution to the reported oddity is to remember that the CPU speed is only part of the overall system performance. While CPU speed has jumped upward considerably (say from 200 Mhz to 1000 Mhz), the basic SDRAM memory speed is still only 100 Mhz, even on the Compaq 7998. (Yes I know that there is 133 Mhz memory, etc. I am not openning that issue right now). The basic memory speed limitation is forcing the Level 2 cache to play a more important roll in keeping the CPU busy. When you calculation fits in L2 cache, you run fast, when it starts to fall out, you run slower due to memory bandwidth issues. While alot depends on how efficiently the cache is utilized, let me give you some examples to illustrate this point. This does not relate directly to prime95, but should illustrate the point. The software used is Proth, by Yves Gallot. The base speed for this is a 200 Mhz Pentium MMX. That scores about 100. The others are relative to this. These are actual machine measurements. Pentium MMX Pentium 3 Pentium 3 Pentium 3 Athlon Number Size 200 Mhz 450Mhz 700Mhz ?L2 700Mhz 512L2 1Ghz 512L2 3*2^64000 + 1 114% 334% 583% 630% 1072% 3*2^128000 + 1 114% 347% 563% 638% 842% 3*2^512000 + 1 118% 357% 268% 464% 735% 3*2^1024000 + 1 126% 341% 263% 452% 631% 3*2^4096000 + 1 128% 316% 272% 462% 442% Notice at smaller number sizes, the productivity relates to CPU speed closely, but at larger number sizes, the productivity degenerates more for the higher CPU speeds. This Athlon measured is the Compaq 7998. The big jump between the Pentium MMX and the Pentium 3 is the addition of a second FPU unit starting the the Pentium Pro line. That means Mr. Gallot as done a good job of programming to utilize the both FPUs efficiently. Lastly notice the cheap 700 Mhz machine in the middle which degenerates to slower than my 450 Mhz machine. That has a lousy memory interface design. Just because the box says 700 Mhz P3 does not mean the rest of the design is any good. At 03:20 AM 7/7/00 -0700, you wrote: >Hi All: > >On several Athlon machines, from 750MHz to 1000MHz, P95 takes >about the same number of clocks per iteration doing a factoring assignment, >in the present case 4.75 billion. The Compaq 7998 settles at 5.28 billion >for the same task, but can be driven down to 4.75 briefly by re-booting, >running ReCache, and then some start/stop/start shenanigans. Soon the number of >clocks starts to drift upward, and settles at 5.28/5.3 again. Other trial >factoring stages show the same anomaly: drift-and-settle always at a higher >than expected number. Trying the Advanced/Time test on the default 10 >mill exponent, I notice unusual variation: from .125 (expected) to .134 >(dreadful) for a 1GHz machine. > >Any insights? ______________________________________________________ _/_/_/ David Underbakke [EMAIL PROTECTED] _/_/_/ _/_/_/ Aramit Technologies,Inc. [EMAIL PROTECTED] _/_/_/ _/_/_/ Res:(763) 577-1400 Bus:(763) 577-1401 _/_/_/ _/_/_/ Fax: (763) 577-1414 _/_/_/ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat Jul 08 18:33:58 2000 From: [EMAIL PROTECTED] Subject: Mersenne: distributing the $$$ Check out http://www.cnn.com/2000/TECH/computing/07/07/seti.implication.idg/index.html - -Ernst _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 08 Jul 2000 17:57:20 -0400 From: Bruce A Metcalf <[EMAIL PROTECTED]> Subject: Mersenne: Rolling Average in Prime95 Greetings, I'm running Prime95 on three slow Windoze95 systems. Just to keep track of system utilization, I periodicaly check the Rolling Average for each machine, with the intent of helping me decide which is in greatest need of an upgrade. I've noticed lately that all three systems -- including one used only as a network dialup server -- have seen abrupt drops in their Rolling Average value, with one system dropping to nearly 500. While I might be using half of all available CPU cycles for other applications, it being only a Pentium 150MHz, it doesn't explain the sharp drops in the Rolling Average of the other two systems which have a constant application load. Is it possible that something in either version 20.4 is miscalculating Rolling Averages, or should I assume that some application of mine is gobbling CPU cycles at a much higher rate than before? Thanks for any insights y'all might care to offer. Bruce A. Metcalf mailto:[EMAIL PROTECTED] http://myweb.magicnet.net/bmetcalf _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 09 Jul 2000 14:35:48 -0400 From: Alan Powell <[EMAIL PROTECTED]> Subject: Re: Mersenne: Rolling Average in Prime95 At 05:57 PM 7/8/00 -0400, Bruce A Metcalf wrote: > ............ , or should I assume that some application of mine is >gobbling CPU cycles at a much higher rate than before? Bruce >From a practical point of view I suggest you download and install the free Microsoft Windows Process Watcher called WinTop from their site. This WinTop utility displays a window showing all Processes running in your machine giving their Identity, %CPU, Accumulated CPU, # Threads, Type and Path. It can be downloaded as part of the "Windows 95 Kernel Toys Set" from: http://www.microsoft.com/windows95/downloads/contents/wutoys/w95kerneltoy/ Downloade the self-unzipping file "W95KRNLTOYS.EXE" into some Temp directory. Double-click to unzip the contents. Instructions are in wintop.txt - viz: Right-click the "wintop.inf" file and select "Install". I keep my short cut under Start/Programs/Accessories/System Tools. I find it quite invaluable in investigating these type of situations. You can fire it up in a few second to investigate some anomalous behaviour or leave it running in the background continuously where it consumes about 0.5% CPU time. Regards Alan Powell [EMAIL PROTECTED] _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ End of Mersenne Digest V1 #756 ******************************
