Sorry it's late today. I know everyone can't make it for more than a few hours after their first cup of joe for the P60 daily report. LOL

Anyone want to start a pool?

I'm going to guess that it only makes it to 96%

Sorry it's late today. I know everyone can't make it for more than a few hours after their first cup of joe for the P60 daily report. LOL

Anyone want to start a pool?

I'm going to guess that it only makes it to 96%

I think it will make it with 2 hours to spare, barring any upload/reporting issues.

But then, I'm an optimist.

---

Calm Chaos Forum...Join Calm Chaos Now

I say it runs into deadline at 85% complete. hopefully (sorry folks) the validators will be off, or atleast the transitioners, and I'll get it back before it's replacement does, and then I'll get credit.

I say it runs into deadline at 85% complete. hopefully (sorry folks) the validators will be off, or atleast the transitioners, and I'll get it back before it's replacement does, and then I'll get credit.

More likely the replacement WU will be a ghost ! Good luck to the old P60.

Now that you have a network card in the beast, have you tried BoincView? It is realy useful for managing a farm, and also gives you predicted "Completion at" times.

---

Sir Arthur C Clarke 1917-2008

here's the benchmarks:

4/30/07 5:38:58 PM||[error] CPU benchmarks timed out, using default values
4/30/07 5:38:58 PM||[error] Benchmark: FP unexpectedly zero; ignoring
4/30/07 5:38:58 PM||[error] Benchmark: int unexpectedly zero; ignoring
4/30/07 5:38:58 PM||Benchmark results:
4/30/07 5:38:58 PM|| Number of CPUs: 1
4/30/07 5:38:58 PM|| 1000 floating point MIPS (Whetstone) per CPU
4/30/07 5:38:58 PM|| 1000 integer MIPS (Dhrystone) per CPU


this must be the ideal golden machine for benchamrks. Mr. Cobbs mythical standard.

OK

here's the second run:
4/30/07 5:44:28 PM||Running CPU benchmarks
4/30/07 5:44:29 PM||Suspending computation - running CPU benchmarks
4/30/07 5:45:30 PM||Benchmark results:
4/30/07 5:45:30 PM|| Number of CPUs: 1
4/30/07 5:45:30 PM|| 38 floating point MIPS (Whetstone) per CPU
4/30/07 5:45:30 PM|| 56 integer MIPS (Dhrystone) per CPU


anyone claime a lower benchmark????

I think that a 40 MHz spark would be slower.

---

Eeeeeee... It's still looking very close...

Will the curve and line converge?

Or is the deadline dead?...

Watch the graph!

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Will the curve and line converge?

Or is the deadline dead?...

Watch the graph!

As the Workunit Turns?

Well, the amount completed in 24 hours seems to be around 3.7 percent. I think it's going to be late, since the deadline is 2 2/3rds days away.

Well, the amount completed in 24 hours seems to be around 3.7 percent. I think it's going to be late, since the deadline is 2 2/3rds days away.

You can stil hope some server outage could help :-)

Peter

The average percentage completed before the turning point (44-48%) was 3.097/day, then it switched gears to 3.683%/day.

Looks like you are out of luck on re-issue, the quorum was met this morning:

http://setiathome.berkeley.edu/workunit.php?wuid=128411733

---

Sir Arthur C Clarke 1917-2008

The average percentage completed before the turning point (44-48%) was 3.097/day, then it switched gears to 3.683%/day.

Looks like it won't make it...

You could always try again with 64MB memory though...

The average percentage completed before the turning point (44-48%) was 3.097/day, then it switched gears to 3.683%/day.

Looks like it won't make it...

You could always try again with 64MB memory though...

Except 64MB installed would probably be only 63.53 MB reported, so the only difference in processing would be having slightly more free RAM. In addition, when Tetsuji's TrigArray chirp method is in use there's about 67 MB allocated to S@H so I suspect it may actually be counterproductive on a system with less than 80MB.

My 200 MHz Pentium-MMX system, host 1033899, is running a prerelease MMX Chicken version which might be ideal for the P60. The general speed improvement from using the Intel compiler and IPP FFTs are supplemented by an FPU chirp method I added which has speed similar to Tetsuji's but doesn't need the large arrays. So rather than having 20 MB free RAM while crunching, the system now has 60 MB free. I still don't know for sure that Intel MMX versions will run on the P60, though I think it likely. Tony, if you want to try it write to jsegur at westelcom dot com.

                                                              Joe

Mr. Segur, I have access to the pre release versions at Lunatics, but I have emailed you anyway.

thanks

I'll be finishing this one up anyway. What's a few more days.

I'll be finishing this one up anyway. What's a few more days.

You never know, you may yet just scrape in with some credit for it...

Good luck!

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

I knew I had an inconsistency in the deadline times but didn't invest the time to find it. Now Josef Segur has emailed me the following:

Something you might want to revise: the "deadline" - "time sent" on the WU
page works out to 24 hours less than the base you have in the spreadsheet
(and seconds are slightly off too). By my calculations it should be
597:27:26 rather than 621:27:09.

I've extracted the UTC times from the Result pages. It shows the result sent on 30 Apr 2007 21:30:29 UTC, and the deadline as 25 May 2007 17:57:55 UTC. I don't have any fancy programs for figuring it out so I looked to see how many days in April, and there are thirty.

Anyway, 2400-2130:29 = 2:29:31 left in april. 2:29:31 Plus time in May (25day + 17:57:55). (25 days X 24 hours) + 17:57:55 = 600 + 17:57:55 = 617:57:55. 617:57:55(time in may) + 2:29:31 (time in april) = 620:27:26.

Hmmm, where am I going wrong? my numbers don't match eachother, let alone that of Mr. Segur.

I've extracted the UTC times from the Result pages. It shows the result sent on 30 Apr 2007 21:30:29 UTC, and the deadline as 25 May 2007 17:57:55 UTC. I don't have any fancy programs for figuring it out so I looked to see how many days in April, and there are thirty.

Anyway, 2400-2130:29 = 2:29:31 left in april. 2:29:31 Plus time in May (25day + 17:57:55). (25 days X 24 hours) + 17:57:55 = 600 + 17:57:55 = 617:57:55. 617:57:55(time in may) + 2:29:31 (time in april) = 620:27:26.

Hmmm, where am I going wrong? my numbers don't match eachother, let alone that of Mr. Segur.

Well, atleast one error is, with deadline on the 25th day, you've only got 24 full days in May and not 25...

So, 2:29:31 + 24*24 + 17:57:55 = 596:27:26

---

"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."

I've extracted the UTC times from the Result pages. It shows the result sent on 30 Apr 2007 21:30:29 UTC, and the deadline as 25 May 2007 17:57:55 UTC. I don't have any fancy programs for figuring it out so I looked to see how many days in April, and there are thirty.

Anyway, 2400-2130:29 = 2:29:31 left in april. 2:29:31 Plus time in May (25day + 17:57:55). (25 days X 24 hours) + 17:57:55 = 600 + 17:57:55 = 617:57:55. 617:57:55(time in may) + 2:29:31 (time in april) = 620:27:26.

Hmmm, where am I going wrong? my numbers don't match eachother, let alone that of Mr. Segur.

Well, atleast one error is, with deadline on the 25th day, you've only got 24 full days in May and not 25...

So, 2:29:31 + 24*24 + 17:57:55 = 596:27:26

Bingo! I had recognized that there were only 24 full days, but subtracted 24 hours rather than recalculating the full thing.

Confirming calculation: go to the Unix time conversion page, convert each date/time to that format, take the difference and convert that value in seconds to hr:min:sec format:

1180115875 - 1177968629 = 2147246 seconds
2147246/3600 = 596.4572222 hours
0.4572222 x 60 = 27.4333333333 minutes
0.5333333 x 60 = 26 seconds

                                                               Joe

OK, Thanks all

Going with 596:27:26 and reworking the chart for tomorrow.