Should be even better now that the workunits should take around twice as long to crunch.

Wonderful, we've solved the problem of WU availability, but now you've effectively cut WU credits almost in half (for me) yet again!

Should be even better now that the workunits should take around twice as long to crunch.

Wonderful, we've solved the problem of WU availability, but now you've effectively cut WU credits almost in half (for me) yet again!

Just because they take longer to crunch doesn't mean that they don't give more credits. :D

---

Unless it's the same credits as the previous amount of work.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Should be even better now that the workunits should take around twice as long to crunch.

Wonderful, we've solved the problem of WU availability, but now you've effectively cut WU credits almost in half (for me) yet again!

No. The longer WUs are granted more credit each.

---

but now you've effectively cut WU credits almost in half (for me) yet again!

Apologies! Problem seems to have been rectified now, but earlier my WU's were running twice as long and still getting same amount of credits.

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

The only problem- and it's a big one- is when you have 'got 0 new tasks' multiple times in a row, which does still happen, and run dry and the reconnect time goes to 2 or 3 hours and you have nothing to crunch until then... any way to change/fix(?) that?

I think the increasing back-off times are built into the BOINC core client, so there's nothing anyone at MW can do about it. Berkeley's idea behind this design was to ease the burden for project servers after being offline for a while (as seems to be common over at SAH), making clients contact them over a longer period of time instead of all at once.

---

Travis, thanks for keeping my beasties fed.

-jim

My quady appears to be much happier now, as does my 2 * work C2D's and my old P4. I wouldn't have thought that decreasing the cached wu's per cpu would work, but this and extending the crunching time of the wu's appears to have done the job! Well done Travis.

I second the two previous posts. Thanks, Travis (also for the work you've done *before* visible success).

---

My i7 is just fine, but my Core2Quad running on GPU is almost never running at its full potential. I usually only get 10 WUs when a request goes in, it crunches 8 in about 5-10 minutes, starts up two, gets a few more, maybe 8 more, sometimes 4, sometimes none. But at any rate, quite often today I've seen my system crunching 6 WUs and having none complete, so it made a request and just got nothing, or perhaps only 6. But I'm pretty positive its not had 24 WUs at any time today.

All running well here, thanks Travis

OK -- what I see is that this works ok *if* the only application running is Milkyway -- I'm doing that as a test on a batch of computers and it does work. However, if one is doing multiple projects (like I normally do), then the small cache tends to result in other projects *with lower resource shares* actually getting a larger proportion of CPU cycles because they have larger caches with similar due dates (examples in particular would be Spinhenge and Poem for me, but it also seems to apply to a lesser degree with SETI, Einstein, Rosetta). The only project which stays reasonable is Climate -- but that's because the due dates are so far out.

I know have work on all computers and including the GPU where I was getting practically nothing.

Server-side, it looks like the change helped work availability quite a bit.

---

Hey now, some of the GPU apps are taking a whole 3 seconds.

Not really. But the latest test app does not use a full CPU core to poll the GPU all the time. That lowers the CPU load quite a bit and therefore the reported time, which is actually the CPU time. Ice has posted already one result that took him mere 0.96 CPU seconds to crunch (but a bit more on the GPU of course).

It is a bit hard to get some meaningful timing for a GPU app. If only one WU at a time would run, one could report the wall clock time. but my app tries to overlap several WUs to increase the GPU load. Therefore the wall clock time is also not reliable (you can have a look in the stderr.txt output). Actually I can let the app report any time you want. So if you have a wish... If you want we can skew the cpcs values (they are skewed anyway with GPU apps) on the stats sites with some creative timing ;)

Hey now, some of the GPU apps are taking a whole 3 seconds.

Not really.
...<snip>...
Ice has posted already one result that took him mere 0.96 CPU seconds to crunch (but a bit more on the GPU of course).
...<snip>...
If you want we can skew the cpcs values (they are skewed anyway with GPU apps) on the stats sites with some creative timing ;)

Yes of course. I have a stopwatch on my mobile, not too accurate for timing but, prior to the increased length WU since yesterday, they were taking around 8 seconds GMT time.

As for the sub-second you quoted above - I caught one even quicker ;)

CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2 cores/threads) 2.79297 GHz (347ms)

CAL Runtime: 1.3.145
Found 1 CAL device

Device 0: ATI Radeon HD 4800 (RV770) 512 MB local RAM (remote 28 MB cached + 512 MB uncached)
GPU core clock: 680 MHz, memory clock: 750 MHz
800 shader units organized in 10 SIMDs with 16 VLIW units (5-issue)
supporting double precision

0 WUs already running on GPU 0
Starting WU on GPU 0
Calculated about 1.85078e+012 floatingpoint ops on GPU, 6.18221e+007 on FPU.
Calculated about 8.03964e+008 floatingpoint ops on FPU (stars).
WU completed. It took 0.953125 seconds CPU time and 25.528 seconds wall clock time @ 2.79307 GHz.

---

Thank you Travis for the other requested changes.

It looks like the changes you and Dave have made are keeping things going smoothly - at least from this end they seem to be. Crunchers are fully fed and have some morsels waiting to gnaw on.

I wonder if any of the GPU crunchers (nice RACs) are equally resplendent with the WU availability?