I had one with 155.591 atoms and 12.5M steps.
It took 19 hours and 25.5 minutes to process on my GTX 980 Ti / WinXPx64 host. The GPU usage was 99%.
The variation of the number of atoms among the workunits of this batch is unusually high (lowest on my hosts is 61.233) which results in unpredictable processing times, which makes the "queuing strategy" quite difficult = slower hosts even miss the 5 day deadline with the workunits having the biggest atom counts, faster hosts could loose the 24hrs or 48hrs bonus (just like mine did).
This batch runs significantly faster on 1080 Ti though.

I had one with 155.591 atoms and 12.5M steps.
It took 19 hours and 25.5 minutes to process on my GTX 980 Ti / WinXPx64 host. The GPU usage was 99%.
The variation of the number of atoms among the workunits of this batch is unusually high (lowest on my hosts is 61.233) which results in unpredictable processing times, which makes the "queuing strategy" quite difficult = slower hosts even miss the 5 day deadline with the workunits having the biggest atom counts, faster hosts could loose the 24hrs or 48hrs bonus (just like mine did).
This batch runs significantly faster on 1080 Ti though.

This CPXB task run on my 980ti only had 64,000 atoms http://www.gpugrid.net/result.php?resultid=16981253 . This received more credit for a far fewer amount of atoms. Maybe these extremely high atom simulations should be their own category.

I had one with 155.591 atoms and 12.5M steps. (lowest on my hosts is 61.233)

I forgot to mention that the awarded credits are the same, regardless the more than twice as much FLOPs needed to process the larger atom count model(s). This is quite neglectful approach of the definition of Cobblestones.
On the positive side, the ratio of such large atom count models to the "normal" atom count models is about 1:20, so this doesn't threatens much the average awarded credits (provided this ratio stays this low).

No, the credit awarded has nothing to do with Cobblestones. It is the CreditNew algorithm that takes full blame. CreditNew is broken. Blame the author David Anderson of SETI for the travesty of CreditNew.

GPU tasks are not using CreditNew. GPU Credit has a fixed value at GPUGrid.

GPU tasks are not using CreditNew. GPU Credit has a fixed value at GPUGrid.

Sorry, I was confused with the previous answer to my questions about the large variance in credit for QMML tasks.

I was told and am certain that those tasks use CreditNew. I was told by the scientists this is so.

GPU tasks are not using CreditNew. GPU Credit has a fixed value at GPUGrid.

Sorry, I was confused with the previous answer to my questions about the large variance in credit for QMML tasks.

I was told and am certain that those tasks use CreditNew. I was told by the scientists this is so.

The CPU Quantum Chemistry tasks might be using CreditNew. When I ran them they were not all the same credit. Esp after like a dozen tasks returned.

GPU tasks here are all fixed. 111k, 252k, 387k and these large 483k credit tasks. (Rounded with Bonus.)

Thanks for the confirmation. Now I have to ask someone who knows how is it possible for the GPUGrid.net project running BOINC software can employ two different credit award mechanisms at the same time.

I didn't think that is possible. Time to ask Richard Haselgrove.