The WUs behave very different on my GPU, some are suitable, some not.
At the moment I can't select the suitable types in my account but get what's available, regardless whether it will crunch fine or very slow.
In CPDN I can select the WU-types according to my systems abilities, and I do so. Of course I have "If none available, send me another type" selected as well, but if possible I only want WUs from HADSM or it's derivatives, they are twice as fast as the others.

Here I would opt for Toni, as it's the only one where I could keep the 1-day preferred crunchtime. On the others I'm sometimes even in the danger of missing the 2-day limit and a second one will be sent as a waste of crunch power.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

This is a problem of workunits. They should all really have the same length.

gdf

This is a problem of workunits. They should all really have the same length.

Same length --> same credits, at least as claim.
As far as I can see it, they claim considerably different credits, so they have considerably different crunch time, even if they would all use the GPU in the same efficiency.

At the moment the problem seems to be enhanced by different efficiency levels of the different types. And all take considerably longer than before, perhaps because more work is done, but definitely with the effect that only a few will reach the requested 1 day limit for return.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

It will take time before the enhanced routines in the faster apps can be incorporated into other research tasks; you can't change the routines mid-research as it would undermine the methodology. You can however, finish a research topic and move on with new improved applications and even use those to add validity to previous work. I'm sure that if improved routines can be applied to all the task types they will be, and this would bring some equality to tasks (in terms of time per step).

It will take time before the enhanced routines in the faster apps can be incorporated into other research tasks; you can't change the routines mid-research as it would undermine the methodology.

That's fine, but why have I to crunch those WUs that don't properly run on my machine and can't stick to those that do?
Why do I have to waste valuable GPU-power on Kashifs or Ibuchs, if it's a well-known fact that they are just a waste of time on my machine?

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

It will take time before the enhanced routines in the faster apps can be incorporated into other research tasks; you can't change the routines mid-research as it would undermine the methodology.

That's fine, but why have I to crunch those WUs that don't properly run on my machine and can't stick to those that do?
Why do I have to waste valuable GPU-power on Kashifs or Ibuchs, if it's a well-known fact that they are just a waste of time on my machine?

I think the request is legitimate. Like in WCG where you can choose which WU (project) you want to process. I am glad I had this possibility otherwise I would have very high error count on certain projects with certain of my devices.

I guess the scientists would need to spend a lot of time making server side changes to facilitate this, but I do like the idea of choice and people being able to chose tasks that run on their systems and not tasks that do not, including myself; when my GTX470’s run KASHIF_HIVPR and IBUCH tasks there are no problems at 715MHz, but if I try to run a GIANNI_DHFR500 at that frequency it usually fails. I’m testing some settings and don’t want to change the 715MHz, but even if I was not if I reduced the cards to stock they would take 18% longer to run all tasks, while if I leave the cards at 715 the GIANNI_DHFR500 tasks would error out and I lose perhaps 18% runtime that way. Neither option is ideal. If I could just select GIANNI_DHFR500 I could leave the cards at stock, or if I could uncheck it I could leave them at 715MHz. In the past I also had cards that would only run some tasks; some always failed after a few seconds, and others usually failed after a random but substantial amount of time.

As well as the administrative overhead and unseen problems, one problem I can see is that people would only run the fastest tasks. If not facilitated correctly this could undermine the other research projects and we would soon run out of some task types. The option to crunch other tasks if no WU’s are available (or not for known cards that fail) would help defeat this problem and if enough people chose to run all tasks (the default setting) then they would just pick up slightly more tasks that others do not like to run. In theory this would on the whole speed up the projects and reduce server overhead (but practice and theory are not the same).

I also think reducing the return deadline to 3 or at most 4 days would help prevent task shortages; to the project a card that takes more than 2.5days to return a task is not worth much – by default boinc cache is 0.5days and tasks are reissued to fast cards that can usually run the task under 12h, so it will get returned inside 3days of the original task being sent, making it irrelevant. It would actually start running within 2.5days from the original task being sent, so after 2.5days (by Boinc default settings) it does not get recalled by the server, even if it does get completed by the first card. Basically, very slow cards just slow the project down as each new task is generated from the results of previous tasks. Seperate these batches out by project and we could frequently find oursleves waiting for 3days for the last task to be returned before the next batch is generated, unless projects were themselves seperated into different runs, which would mean a project rethink.

Until all the projects use the faster code, and perform equally (if this is even possible) there would be an inherent points attraction to faster projects, and nothing to offset this. My guess is that most people don’t know what projects there are, so they are not going to chose for any other reason, with the obvious exception of the HIV tasks. This is probably not a good thing.

Then there is the matter of all those crunchers choosing the wrong settings, and CA’s can’t change these (to do with Boinc not GPUGrid), so it would mean more work for the scientists and probably creating default setting parameters so that cards would not get tasks if they are known to fail those task types, until this is unchecked by the user (say after a driver update). But if the user did not do this they would just stop picking up tasks altogether, or until some default settings kicked in again.

> Could there be a selection for distinct WU-types in our accounts?

It's been suggested, seconded and third-ed. I'll enthusiastically 4th it!

I'd suggest a checkbox for each general WU type with another checkbox for "If no work for selected applications is available, accept work from other applications?" like AQUA, NFS, PrimeGrid and others.

We submit different Wus every week. As far as I understand other projects use different application names to let people select which WU to crunch, but in our case this would be impossible.

gdf

Quoting gdf,

"As far as I understand other projects use different application names to let people select which WU to crunch, but in our case this would be impossible."

Hmmm, 20 years this project wouldn't have existed without ALL the hardware and support systems needed to accomplish GPUGRID objectives. Now it's down to software and programming. From your point of view, you believe you are up against a brick wall with no place to go. I fourth, fifth, sixth, seventh,....nth degree with others to make a selection process occur.
In other words,"Make it happen!"

Or in a movie 33 years ago, "you believe not, because you think not?"

We submit different Wus every week. As far as I understand other projects use different application names to let people select which WU to crunch, but in our case this would be impossible.

You have fixed credits, so you know beforehand how laborious each WU will be.
I know from my experience which WUs will make the 2-day deadline before capacity wasting sets in.
I would choose WUs with less than 5500 credits claim, with a possibility to extend this to 9000 if no small one is available. Longer ones are useless on my system.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

We submit different Wus every week. As far as I understand other projects use different application names to let people select which WU to crunch, but in our case this would be impossible.

gdf

That should be easy to overcome. All you have to do is name the same executable several different names and assign different WU types to each uniquely named "exe". Doesn't seem that this would be a problem.

We submit different Wus every week. As far as I understand other projects use different application names to let people select which WU to crunch, but in our case this would be impossible.

You have fixed credits, so you know beforehand how laborious each WU will be.
I know from my experience which WUs will make the 2-day deadline before capacity wasting sets in.
I would choose WUs with less than 5500 credits claim, with a possibility to extend this to 9000 if no small one is available. Longer ones are useless on my system.

Bump.

It's really annoying that, although you know beforehand how big the WU will be, you still send really huge ones to normal computers, where they will miss the 2-day deadline. Every work on WUs that takes more than 2 calendar days is completely futile, as it's sent to another computer to be crunched there as well.

If you could just write the credit claim somewhere in the name of the WU we could easily see what will run and what not. Better still would be to have this option here in my account, or decided by BOINC on previous results. If a certain type of WU takes more than 2 days to report, only send smaller ones to that machine.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki