I currently have the longest running workunit up to now. 7 h run time were already done and approx. 8 h were still to go, when I had to close BOINC. After restart, it started again at 0 % progress, but run time started at the approx. 7 h were I stopped it before. So currently I am at 5.4 % again and the total run time has risen from 15 h to approx. 22 h now.

Just for the records (because we now have moved to a new app version): the workunit mentioned above was finished this morning and is now validated. The stderr out has some interesting info about the checkpointing problem, excerpt:

Checkpoint: tnow = 1.20291. time since last = 360.466s
Checkpoint: tnow = 1.22032. time since last = 361.073s
Checkpoint: tnow = 1.238. time since last = 360.637s
Checkpoint: tnow = 1.25557. time since last = 362.311s
Checkpoint exists. Attempting to resume from it.
Thawing state
Didn't find header for checkpoint file.
Number of bodies in checkpoint file does not match number expected by context.
Got checkpoint file for wrong type. Expected sizeof(real) = 8, got 0
Trying to read interrupted checkpoint file
Failed to find end marker in checkpoint file.
Failed to resume checkpoint
Removing checkpoint file 'nbody_checkpoint'
Starting fresh nbody run
Starting nbody system
-38.146212235604 2.2104695431195 32.223568725294
69.480777935001 95.95483517654 -100.99755377651
Checkpoint: tnow = 0.0197762. time since last = 903435s
Checkpoint: tnow = 0.0406272. time since last = 394.064s
Checkpoint: tnow = 0.0593286. time since last = 366.626s

Btw, claimed credit 495.43, granted credit 65.73 is a bit disappointing. Never mind. ;)

Are you seeing a lot of WUs with granted credit much lower than the claimed credit? I don't think that should be happening.

---

Are you seeing a lot of WUs with granted credit much lower than the claimed credit?

No. None with such big differences. My guess was that in the above case it was caused somehow by the restart, the checkpoint bug and the ongoing count of the run time, making the total run time somewhat bigger than it actually was.

Is this new, drastically longer nbody search in preparation for new GPU apps, or are they just longer to keep less load on the server?

Yeah, I'm being a intentionally aannoying about wanting a GPU app because quite frankly, I'd like to be putting my processing power towards something a bit more important than trying to prove/disprove a mathematical conjecture.

Is this new, drastically longer nbody search in preparation for new GPU apps, or are they just longer to keep less load on the server?

They are longer because they are going to be actual work units. The 4096 ones have just been for testing the application and the actual search. More bodies are needed for enough resolution. The work unit times also vary drastically depending on the other parameters. For 10,000 bodies the worst case runs for around 12 hours, to only a few minutes in the best cases.

Yeah, I'm being a intentionally aannoying about wanting a GPU app because quite frankly, I'd like to be putting my processing power towards something a bit more important than trying to prove/disprove a mathematical conjecture.

That will happen eventually. It mostly depends on how much time I have after homework and classes this semester. The O(n log n) tree n-body will be somewhat tricky to get working on the GPU, while the basic O(n^2) one is pretty trivial and seems to be the most commonly used GPGPU example. I'm not sure how long it will take to get working. First I'm trying to get a working OpenCL version of the separation code, which is mostly done. We're also talking about doing the rough phases of the search with single precision which would allow more GPUs to work on it.

We're also talking about doing the rough phases of the search with single precision which would allow more GPUs to work on it.

Would this be an application which does a part of the calculations on the (single precision) GPU and the other part on the CPU? A bit like the current Einstein CUDA application, using the GPU really as a coprocessor? Sounds interesting.

Would this be an application which does a part of the calculations on the (single precision) GPU and the other part on the CPU? A bit like the current Einstein CUDA application, using the GPU really as a coprocessor? Sounds interesting.

No. I only know a little bit about the search; this is Travis' area. It would be more like double precision results would only be needed as the likelihoods get closer. The float result is significantly different from the double result, but still close enough to be sort of useful. Lots of float results could be used to do a rough search, and then as the fitnesses get closer, double results would be needed.

Hi

My one finally finished at 25 hours 27 minutes with a CPU time of just under 17 hours and got 213 points or just over 8 points an hour. this seems very low as I think most other projects give more than this.
what do others think?

regards Paul

No. I only know a little bit about the search; this is Travis' area. It would be more like double precision results would only be needed as the likelihoods get closer. The float result is significantly different from the double result, but still close enough to be sort of useful. Lots of float results could be used to do a rough search, and then as the fitnesses get closer, double results would be needed.

That idea was thrown around for the other applications too, but at the time it meant setting up a second project for the single precision work. If you can make it work for the nbody search, I wonder if the other searches can switch over to a similar system?

Yeah, I'm being a intentionally aannoying about wanting a GPU app because quite frankly, I'd like to be putting my processing power towards something a bit more important than trying to prove/disprove a mathematical conjecture.

There are SETI WUs for GPUs that you could run -- assuming they ever get their air conditioning problems fixed so their servers can be put back on line. :-(

---

some wu's were not validated due to 'Checked, but no consensus yet'
One example:
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=196605674

Alexander

some wu's were not validated due to 'Checked, but no consensus yet'
One example:
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=196605674

Alexander

<search_likelihood>-1662.3825647507408</search_likelihood>
<search_application>milkywayathome nbody 0.04 Windows x86 double</search_application>


<search_likelihood>-50430.548520685144</search_likelihood>
<search_application>milkywayathome nbody 0.07 Windows x86 double</search_application>

Something changed in the calculations?

my latest one took 26 hours so you can see it has hogged one of my cpus for a whole 24 hours and I just get credits of 213 again
this seems very low and I may be detaching soon although I have done this project for 17 months

paul

Same here 90 hours for one and 75 for an other,
But that's a lot of data :->

---

as an example I have just got 141 credits on another project for 7 hours so they a giving 20 credits an hour not 8
Paul

boinc manager do not manage to download the apps for uts 64 b 0.06 No body, why do you think?

I app_info this file, maybe that comes from there?

<app_info>
<app>
<name>milkyway</name>
</app>
<file_info>
<name>astronomy_0.21_x64_SSE3.exe</name>
<executable/>
</file_info>

<app_version>
<app_name>milkyway</app_name>
<version_num>21</version_num>
<file_ref>
<file_name>astronomy_0.21_x64_SSE3.exe</file_name>
<main_program/>
</file_ref>
</app_version>

<app_version>
<app_name>milkyway</app_name>
<version_num>20</version_num>
<file_ref>
<file_name>astronomy_0.21_x64_SSE3.exe</file_name>
<main_program/>
</file_ref>
</app_version>

<app_info>
<app>
<name>milkyway_nbody</name>
</app>
<file_info>
<name>milkyway_nbody_0.06_windows_x86_64__sse2.exe</name>
<executable/>
</file_info>
<app_version>
<app_name>milkyway_nbody</app_name>
<version_num>6</version_num>
<file_ref>
<file_name>milkyway_nbody_0.06_windows_x86_64__sse2.exe</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>


<app>
<name>milkyway</name>
</app>
<file_info>
<name>milkyway_0.24_windows_intelx86__cuda23.exe</name>
<executable/>
</file_info>
<file_info>
<name>cudart.dll</name>
<executable/>
</file_info>
<file_info>
<name>cutil32.dll</name>
<executable/>
</file_info>
<app_version>
<app_name>milkyway</app_name>
<version_num>24</version_num>
<plan_class>cuda23</plan_class>
<avg_ncpus>0.040000</avg_ncpus>
<max_ncpus>0.040000</max_ncpus>
<coproc>
<type>CUDA</type>
<count>1</count>
</coproc>
<file_ref>
<file_name>milkyway_0.24_windows_intelx86__cuda23.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>cudart.dll</file_name>
</file_ref>
<file_ref>
<file_name>cutil32.dll</file_name>
</file_ref>
</app_version>

<app>
<name>milkyway</name>
</app>
<file_info>
<name>milkyway_0.03_windows_intelx86__cuda23.exe</name>
<executable/>
</file_info>
<file_info>
<name>cudart.dll</name>
<executable/>
</file_info>
<file_info>
<name>cutil32.dll</name>
<executable/>
</file_info>
<app_version>
<app_name>milkyway</app_name>
<version_num>3</version_num>
<plan_class>cuda23</plan_class>
<avg_ncpus>0.040000</avg_ncpus>
<max_ncpus>0.040000</max_ncpus>
<coproc>
<type>CUDA</type>
<count>1</count>
</coproc>
<file_ref>
<file_name>milkyway_0.03_windows_intelx86__cuda23.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>cudart.dll</file_name>
</file_ref>
<file_ref>
<file_name>cutil32.dll</file_name>
</file_ref>
</app_version>

</app_info>

---

Team Alliance francophone, boinc: 7.0.18

GA-P55-UD5, i7 860, Win 7 64 bits, 8g DDR3, GTX 470

We're at v0.07 for Windows already, please see here: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=1917

my latest one took 26 hours so you can see it has hogged one of my cpus for a whole 24 hours and I just get credits of 213 again
this seems very low and I may be detaching soon although I have done this project for 17 months

paul

That's strange ... I just completed a WU that took 8.15 hrs total run time and 7.53 hrs CPU time on a dual core 2.4Ghz AMD running Windows XP 32 and was granted 213.76 points.

---

my latest one took 26 hours so you can see it has hogged one of my cpus for a whole 24 hours and I just get credits of 213 again
this seems very low and I may be detaching soon although I have done this project for 17 months

paul

That's strange ... I just completed a WU that took 8.15 hrs total run time and 7.53 hrs CPU time on a dual core 2.4Ghz AMD running Windows XP 32 and was granted 213.76 points.

Never mind ... that was NOT an n_body WU! (Engage brain before activating keyboard... :-) ).