Oh wow, good to know about the MMX app. I will try the Linux version with my Pentium Classic after if finishes reinstalling.

There's a good chance it will work, but possibly not. The Intel compiler would insert MMX code if it decided that was optimal, but MMX is only integer and all significant S@H calculations need floating point.

                                                                  Joe

wholey smokes! It might make it now, thanks to the opt app. Has 4 hours CPU time and already at 1.280% complete. 4 hours X 6 hours =24 hours, so 1.280 X 6 = 7.68% per day. That more than twice the previous 3.09%/day it started with last time.

If it could keep up that rate, both the WUs it was assigned might be finished within deadline. But I don't really expect that much improvement, the SSE or better optimized versions may achieve that much advantage over stock but without SIMD I expect something more like a 30% improvement. The 0.393 AR helps too, the formula the splitter uses for estimates is quite generous in that range.

                                                                 Joe

Here's what CPU-Z says about this processor. Doesn't seem to have as much data as my newer computers.

Here's what CPU-Z says about this processor. Doesn't seem to have as much data as my newer computers.

Does L1 & L2 Cache's say 0kytes?, are they turned on in the Bios?,
L2 will be on the motherboard, and might not be readable,
but i would have thought it would say the L1 Size.
One of my mates at work had his L2 turned off for some strange reason.

Claggy.

---

Sorry about the bad pic quality. I shrunk it from 680 to 600 pixels. Takes about 3 min just to load Adobe Photoshop, and then about one min per operation. L1 and L2 are both 8kbytes.

L1 and L2 are both 8kbytes.

Don't you mean L1 code and L1 data caches are both 8K? The L2 (if the motherboard actually came with any) should be much bigger (at least 64K if not 128/256K).

---

These tiny L1 caches explain everything. I wonder how a processor at these clock speeds would have performed if it had 64+64kb L1 cache on it.

---

These tiny L1 caches explain everything.

You should have seen them before they had any cache built into the CPU, such as the 386 and earlier. It wasn't until the 486 that they included the L1 cache, but it wasn't segregated code/data like the Pentium's. The Intel 486 had a total of 8KB (DX4 had it increased to 16KB).

---

@Ozzfan, see...I told you the graphics were bad....LOL.

Anyway, It didn't keep up 7%/day, but is holding more than 5%. Meaning, it should make the deadline.

These tiny L1 caches explain everything. I wonder how a processor at these clock speeds would have performed if it had 64+64kb L1 cache on it.

Actually, the biggest gain in performance is made by fitting the entire application and data in physical ram and preventing paging to disk. This is because disk accesses are orders of magnitude slower than ram (measured in milli-seconds as opposed to nano-seconds for ram, i.e. approximately 10^6), so even a small amount of page file access dramatically slows a cpu bound application.

If I remember correctly, win95 has some sort of application (is it perfmon?... in system tools perhaps) which will monitor paging (although in 48 MB of ram, running it may itself cause paging). However, my point is that probably the biggest gain in performance will be to increase the amount of ram available to s@h since s@h is cpu bound and its performance will suffer most by waiting for disk accesses, if they are occurring.

My feeling is that, with enough ram. the P60 should be better than marginal, I know my P100 (with the very unoptimized stock linux app) is not marginal and there is not that much difference in real world performance between the processors, even cpu bound.

Brendan

Two days later.....Look at her go!!

The 'to completion' line should be starting back down around now. :)

---

Wow, I thought I'd post the next update after 3 days, and thought that was tomorrow, but It seems that's today. I'll wait for tomorrow anyway. It hasn't turned yet, but should tomorrow sometime (after tomorrows posting). Last time it turned somewhere between 44 and 48%. At the present time it's at......43.439%, 189:18:10 cpu time, 113:23:20 to comp, so it should be soon.

[Edit], upon further study, this mornings to comp was 113:34:16, so it turned sometime today, but won't be reflected until tomorrow or the next update. [/edit]

so is the work unit going to make it this time?

---

I guess it won't make it. I went to collect the data and found this:

6/10/07 3:26:39 AM|SETI@home|Reason: Unrecoverable error for result 06mr05aa.19631.4800.747130.3.78_1 (Maximum CPU time exceeded)
6/10/07 3:26:44 AM|SETI@home|Computation for task 06mr05aa.19631.4800.747130.3.78_1 finished
6/10/07 3:26:47 AM|SETI@home|[file_xfer] Started upload of file 06mr05aa.19631.4800.747130.3.78_1_0

Even though all signs pointed to it finishing in 2/3rds the time to deadline. I'm using Boinc 5.8.16 on this.

GRRRRRRRRRRRRR

Upgraded to 5.10.4 (32b ofcourse).

New benchmarks are 38/55

I guess it won't make it. I went to collect the data and found this:

6/10/07 3:26:39 AM|SETI@home|Reason: Unrecoverable error for result 06mr05aa.19631.4800.747130.3.78_1 (Maximum CPU time exceeded)
6/10/07 3:26:44 AM|SETI@home|Computation for task 06mr05aa.19631.4800.747130.3.78_1 finished
6/10/07 3:26:47 AM|SETI@home|[file_xfer] Started upload of file 06mr05aa.19631.4800.747130.3.78_1_0

Even though all signs pointed to it finishing in 2/3rds the time to deadline. I'm using Boinc 5.8.16 on this.

GRRRRRRRRRRRRR

Sorry to hear that. There's a new version of SETI Beta MultiBeam ver.5.21 out. Eric may be glad to see your PC on there.

Also I beleive PrimeGrid may be suitable for a low spec machine.

Good Luck

---

Sir Arthur C Clarke 1917-2008

Actually those are default values. see log below. This was the automatic run, a manual rerun produced the same.
6/10/07 10:00:36 AM||Running CPU benchmarks
6/10/07 10:05:37 AM||[error] CPU benchmarks timed out, using default values
6/10/07 10:05:37 AM||[error] Benchmark: FP unexpectedly zero; ignoring
6/10/07 10:05:37 AM||[error] Benchmark: int unexpectedly zero; ignoring
6/10/07 10:05:38 AM||Benchmark results:
6/10/07 10:05:38 AM|| Number of CPUs: 1
6/10/07 10:05:38 AM|| 38 floating point MIPS (Whetstone) per CPU
6/10/07 10:05:38 AM|| 55 integer MIPS (Dhrystone) per CPU

I seem to recall reading the BM timeout in the latest dev version was reduced to 30 seconds, so that's probably the reason for that.

Alinator

<edit> Astro, it clicked for me! There was a post over in the Q/A forum about a host which had errored a result on Max Time. It turned out that the host had ended up with a 'zeroed' BM run, which when CC went to check to make sure the results were on schedule lead to the result 'faulting' because of the divide by zero to get the calculated max time.

You might be able to work around that by manually setting appropriate values for the old timer from past experience and then start the CC with the fixed BM switch (don't recall its exact syntax, but it's listed in the BOINC docs).

HTH,

Alinator

I rebooted to clear andy memleak issue that might have crept in. Reran benchmarks and got the same thing. Add /benchmark_debug to the cc_config and got:
6/10/07 10:38:12 AM||Suspending computation - running CPU benchmarks
6/10/07 10:38:14 AM||[benchmark_debug] Starting floating-point benchmark
6/10/07 10:38:25 AM||[benchmark_debug] Ended floating-point benchmark
6/10/07 10:38:29 AM||[benchmark_debug] Starting integer benchmark
6/10/07 10:38:39 AM||[benchmark_debug] Ended integer benchmark
6/10/07 10:38:42 AM||[benchmark_debug] Ended benchmark
6/10/07 10:38:43 AM||[benchmark_debug] 0 out of 1 CPUs done

........snipped out 5 more pages of the last message which went on for nearly 5 minutes

6/10/07 10:43:10 AM||[benchmark_debug] 0 out of 1 CPUs done
6/10/07 10:43:12 AM||[error] CPU benchmarks timed out, using default values
6/10/07 10:43:12 AM||[benchmark_debug] CPU 0 has finished
6/10/07 10:43:12 AM||[benchmark_debug] 1 out of 1 CPUs done
6/10/07 10:43:12 AM||[benchmark_debug] CPU 0: fp 0.000000 int 0.000000 intloops 0.000000 inttime 0.000000
6/10/07 10:43:12 AM||[error] Benchmark: FP unexpectedly zero; ignoring
6/10/07 10:43:12 AM||[error] Benchmark: int unexpectedly zero; ignoring
6/10/07 10:43:12 AM||Benchmark results:
6/10/07 10:43:12 AM|| Number of CPUs: 1
6/10/07 10:43:12 AM|| 38 floating point MIPS (Whetstone) per CPU
6/10/07 10:43:12 AM|| 55 integer MIPS (Dhrystone) per CPU


I'm going to uninstall adn reinstall some earlier version of boinc.

brb