I'm not going to provide links, but I noticed that the wingman on one of my Cullen LLR WUs had already returned the result -- in one fifth the time it takes my computer to do it. Looking at the wingman's computer, it's returned many of them that quickly, and they all validated correctly.

My computer is a C2Q, his is an i5. No CPU is currently fast enough to do the calculations that quickly; with current architectures you would need to be running above 10 GHz or maybe higher.

The only conclusion is that he's running a GPU version of LLR under an anonymous platform. He's running Cullen and Woodall using the anonymous platform mechanism, both with exceptionally fast run times. Other LLR WUs, which are not using an anonymous platform, are showing normal run times on the same computer.

So, does anyone know anything about the status of GPU-LLR programming right now? It seems like someone is making some serious progress.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

So, does anyone know anything about the status of GPU-LLR programming right now? It seems like someone is making some serious progress.

I am in a position to make llrCUDA work with BOINC relatively quickly, I think, but I haven't done so yet. And no Windows builds are working right now, that I know of.

Were you going by elapsed time or by date and time of return minus date and time of send? I've noticed in some cases the wrapper can forget about elapsed time previously spent on a WU when it restarts.
____________

So, does anyone know anything about the status of GPU-LLR programming right now? It seems like someone is making some serious progress.

llrCUDA at Mersenne forum is worth watching.
(I haven't seen Windows build to test it myself)

When running anonymous platform using old wrapper and client got restarted, it was reporting wrong run time (ie. it goes to zero upon restart, even task is 75% finished and continue from checkpoint). I even have results showing 15k, 10k or 5k sec on C/W LLRs.
It results in unbelievable low run-time and even lower credit, albeit real run-time was in ~150k sec expected range.
____________
My stats
Badge score: 1*1 + 5*1 + 8*3 + 9*11 + 10*1 + 11*1 + 12*3 = 186

It results in unbelievable low run-time and even lower credit, albeit real run-time was in ~150k sec expected range.

It results in unbelievable low run-time and even lower credit, albeit real run-time was in ~150k sec expected range.

This will also be a problem as soon as we have a llrCUDA ready for BOINC... with the current credit system, we'll have high credits (if two CPU results validate against each other), medium credits (CPU vs GPU) and low credits (two GPUs) for similar WUs.

LLR should use an algorithmic server-side formula based on n, k, digits, FFT size etc that takes client claim out of the picture. However, I'm not sure how easy it is to come up with a single formula that copes equally well with PPS and SoB WUs for instance. The aim would be to reward work done, rather than how it was done - the same formula would apply regardless of CPU versus GPU etc.
____________

I'm pretty sure SETI@home has a similar scenario -- credits based upon run-times and CPU vs, GPU validations -- and I don't remember having a problem there with credits being too low on GPU apps. It's been over a year since I crunched there, however, so I might be remembering some of the details incorrectly.

LLR should use an algorithmic server-side formula based on n, k, digits, FFT size etc that takes client claim out of the picture.

So, does anyone know anything about the status of GPU-LLR programming right now? It seems like someone is making some serious progress.

LLR should use an algorithmic server-side formula based on n, k, digits, FFT size etc that takes client claim out of the picture. However, I'm not sure how easy it is to come up with a single formula that copes equally well with PPS and SoB WUs for instance. The aim would be to reward work done, rather than how it was done - the same formula would apply regardless of CPU versus GPU etc.

When running anonymous platform using old wrapper and client got restarted, it was reporting wrong run time (ie. it goes to zero upon restart, even task is 75% finished and continue from checkpoint). I even have results showing 15k, 10k or 5k sec on C/W LLRs.
It results in unbelievable low run-time and even lower credit, albeit real run-time was in ~150k sec expected range.