Has anyone ever tried this at GPUGrid?

It's commonplace at other projects with smaller tasks, and Einstein@home have just announced an experiment in enabling the option via project preferences.

I'm going to try it overnight on my GTX 470, first of all with small-task projects (SETI and Einstein). If that works well, and if nobody here comes up with any show-stoppers, I'll try adding GRUGrid to the mix tomorrow or the next day.

I'm planning to set count=0.48 for the other two projects, and count=0.51 here. That would allow any combination of two tasks from {Einstein, GPUGrid, SETI} to run, except two GPUGrid simultaneously.

I'm currently running short tasks only on that host, and they take no longer than 5 hours. Since I'm already alternating the tasks with SETI, I don't expect that my return-rate will be made much, if any, slower by running concurrently - but testing that expectation is part of the reason for my experiment.

Comments?

I've already run tasks for 'ACEMD2: GPU molecular dynamics v6.16', so I have the executables and the <app_version> segment, which will allow me to construct app_info.xml with no bother at all. Been there, done that.

I'm not specifically asking about 'benefit', certainly not for the GPUGrid processing itself. I'm more thinking about the other projects. Both SETI (during the startup phase of each - short - task), and Einstein (throughout the task) have periods when the app doesn't make efficient use of the CUDA cores - either because data is being pre-processed and loaded into video memory by the CPU, or because some parts of the calculation are not amenable to parallelisation and have been deliberately left for CPU processing.

Running two tasks at once allows one of them to make use of the CUDA cores while the other is attending to other matters. My question is: can GPUGrid join the party without detriment?

A bit OT:
I did many tests about it (9600GT, GTX 260, GTX 560Ti CC2.1) one year ago. The most useful for Einstein or Seti seemed to be F@H. I have found it more efficient than running concurently Einstein&Einstein or Einstein&Seti or Seti&Seti dute to possibility to set GPU load by F@H client. GPUGRID I didn't test.

A bit OT:
I did many tests about it (9600GT, GTX 260, GTX 560Ti CC2.1) one year ago. The most useful for Einstein or Seti seemed to be F@H. I have found it more efficient than running concurently Einstein&Einstein or Einstein&Seti or Seti&Seti dute to possibility to set GPU load by F@H client. GPUGRID I didn't test.

Well, the experimental host has completed A565-TONI_AGG1CMAP-5-50-RND4946_2. As you can see, it's a _2 resend, so two hosts have failed before me - so the accepted result has to be a bonus.

It took just over 30 Ksec, compared with a usual ~13.2 Ksec when running these tasks on their own (unshared). So less than half speed, which won't impress the chasers after efficiency, but not a complete disaster either.

I'l let the next task - a TONI_AGGMI - run in the same configuration, to get a second comparison point. Then, I'll try freeing up a CPU core, and see what difference it makes.

Second task complete - A1823-TONI_AGGMI1-34-100-RND3451_3. Again, I succeeded with a task that two had crashed (and a third timed out on) before me. So, worthwhile for the science.

This one took 41 Ksec, against ~17.5 Ksec, so fairly consistently taking about 2.3 times as long as a task running alone. Not worth doing normally, unless you're interested in these sorts of multi-project experiments. Next, to see what happens with a free CPU.

I did some testing. I found it easy on Einstein since their units are the same size. Here I see it more complicated. The results are very good since standard dev is very small.

http://einstein.phys.uwm.edu/forum_thread.php?id=9361&nowrap=true#116431




____________
HOW TO - Full installation Ubuntu 11.10