I see your host has now a mix of old and new WUs

One more thing: while the workunit mentioned above was sent only recently, it was generated already on the 23rd of April, so it is still one of the "tweaked" workunits. Once the newly generated workunits are reached out, we should see a reduced memory usage and some modest performance increase.

Cheers
HB

Thanks for the feedback.

We would also be interested to hear about graphics RAM usage, especially when crunching workunits that were generated beginning from 28th of May.

Cheers
HBE

This implies that slow CPUs will slow down OpenCL workunits much more than they slow down CUDA workunits.

2h/WU and i have 4 Validate error.
ATI Radeon 5970 (GPU/MEM 725/600).


http://albert.phys.uwm.edu/results.php?hostid=1678&offset=0&show_names=0&state=4&appid=

I'm guessing the admins don't quite get what our little underground (for lack of a better term) group of beta testers do. Whenever a new project pops up, word gets passed around through or team forums, IRC channels, etc. There's some hardcore guys with enough cores and gpus to put a serious strain on a new project.

Some jump in just for the chance to beta test, some jump in to add another new project to a certain milestone or two. I'm in that group, love to throw my cpus and gpu's on a new project, in hopes of adding another million credit project to my pile of 40ish I've done already.

Seems like admins doesn't want us here. Which is a shame, this is what we do.

Please, update your hosts with this builds. ATi and NV builds got speed increase, HD5-version added, NV version added.

CPU builds got some updates too.

Known issues:
1) As with OpenCL AstroPulse, last driver version from both vendors show increased CPU usage. AMD already aknowledged this issue and promised to fix in new Catalyst releases, NV still keeping silence about this issue.

2) OpenCL NV app can silently (i.e., w/o errors in stderr) produce incorrect results (overflows). Again, situation resembles NV AstroPulse rev521 case and usually means too long kernel call. Why NV OpenCL runtime doesn't report error code for kernel enqueue runtime call - no idea. But low-end NV GPUs could be not capable to use this app. This testing should determine GPU requirements for NV app too.

Thanks, I downloaded the WU and confirm the difference.

At least part of the problem is a long-standing issue which is seen in SETI@home Enhanced between the stock CPU and stock CUDA applications too. The most efficient order to do the various searches is different for CPU and GPU, so for this kind of task with a lot of potential signals the CPU finds a different subset than the GPU does. Eric Korpela is aware of the issue and maybe if he or Jeff Cobb get a chance the Validator code will be revised to judge quick overflow results differently.

The way that's pertinent to this case is the MB7 r365 sources are primarily targeting openCL builds so the Autocorr and Spike searches are done in a different order than stock 6.97.

At first glance, that doesn't seem to explain all the differences between the MB7 CPU result and 6.97 result. I need to analyze more to really be sure what the data indicates.

FWIW, those results will be considered "weakly similar" and both get credit when the third result is returned.