Just a heads up, I will be starting new runs over the next couple days that will have a different step size in a computationally intensive section of our code. Through some work we did, we found that this step size could be optimized and reduced to improve the speed at which our code runs without sacrificing accuracy. We expect to see these runs complete in about 1/5th the time depending on the platform. Credits will hopefully still be calculated correctly, but if you think they are not for these runs please post here. If these runs cause you any trouble with these runs or you notice you stop receiving work units please post that here too. These runs will all include the tag _fast_ in the work unit name so it should be easy to track.

For now, these optimizations will only be used on the Modfit code, but in the near future we plan on also using them on original separation code, too.

If you have any questions about this optimization or problems, please let me know,

Any chance to look at the high error rate of current Modfit units ?
I have no issues with the default MW application, only a few errors during several days.
Today I gave Modfit another chance, but after ~1 hour I have disabled them again - 10 invalids during such a short period and that's probably not the end.

After some checking, I think the credits might actually be scaled properly based on the number of flops required to complete the work unit. The problem is that now the runs might not fully utilize your GPU. It might be a good idea to try configuring your GPU to run 2 of these at the same time and see if that makes a difference.

It might be a good idea to try configuring your GPU to run 2 of these at the same time and see if that makes a difference.

Jake

That might be a problem because the normal modfit takes 98% of the GPU (with a CPU core to feed it)
If I can make a choice to do only 'fast' modfits it might work with 3 at the same time because it only take about 33% of the GPU (sometime less)

We will be switching over to using only fast runs as these slow ones finish up. You can expect them to be all the faster runs by the end of the week.

Thank you for the feedback,

Jake

On a slightly different topic, since yesterday nearly every single unmodded ask I've processed has ended up as a computational error, some 30 odd before I realised what was going on, nothing has changed on my rig...
Has there been an alteration at MW@H end?
I've stopped processing the affected WU and am now only doing modified, seemingly without problems other than delayed validation.

Hi Tom,
Yup, trouble is, 'every' task of that type fails the same way.. I cannot see any point in processing them, if they are all going to fail.
All they do is utilise my GPU and block other WU that can be processed.

I'll continue to process the modfitts until the others are sorted out.

Jeff put up some new runs with a bad parameter file. He said they are are fixed now so it should be good to run them now. There may still be a couple in the crunch queue but that should clear itself soon.

Sorry for the trouble.

Jake

[Edit]

The "Slow" runs are still running because it seems I am still getting good results from them. I would hate to kill them before they were done. Sorry for the delay, but these runs are still being useful and will be run a little while longer.

My 7970 graphics cards can each tear through a "fast" workunit in 8-12 seconds, but then there is a 2-6 second pause while BOINC does whatever it does between workunits before the next one starts. This is highly inefficient from a processing point of view. Even my poor 6 year old Radeon HD4650 can crunch these units quickly (70 seconds).

WE NEED BIGGER WORKUNITS FOR GPU's.

WE NEED BIGGER WORKUNITS FOR GPU's.

WE NEED BIGGER WORKUNITS FOR GPU's.

That being said, de_nbody_08_05 has tied up 7 CPU cores for 37 hours. 8(

Problem with adding buffer, it adds buffer for CPU and GPU and you cannot separate. Since I want my CPU not to buffer the work it is doing, the short units are causing a lot of non-work time because of the time it takes to process the finishing and downloading the next unit.

Save the file as "app-config.xml" and place the file here:
(Unhide your folders if you haven't already)
Program data\Boinc\Projects\MilkyWay
Restart Boinc and you'll be running two at a time.

I'm afraid that did nothing on neither my dual GPU machine nor my single GPU box. :( Not even after triple checking I'd followed the instructions.

So, having successfully (but unintentionally) 'hijacked' a thread, I'd like to try and return the focus to these fast work units.

These fast units, due to the standard GUI interface issues of the BOINC client, don't keep the GPU's busy enough. I've dropped from almost a million credits per 24 hours to 650k a day. I don't give a crap about the credits, the point is that these efficient fast WU's have resulted in almost a third less processing power, apparently.

Again, even my lowly 6 year old ATI HD4850 can crunch these WU's very quickly. And if it's possible from a computer science perspective, I think the project would better benefit from a denser, more prolonged set of WU's, that help to minimize/offset the 2-6 seconds of 'downtime' that occurs between WU's.