I'd also like to put a note out there to people running scripts to cancel WUs from certain searches, asking you to stop. These can lead to some bad server problems where some WUs accumulate on the server because they're not being processed fast enough. We'll be taking some steps on the server end to stop this kind of activity, but until that gets finished I'd like to ask people to stop. If it continues I'll start banning or zeroing out offending users credit. --Travis

---

Hi,
I have some Mikyway's WU that are calculate to more than 100% .
So I canceled them !
Should I let them go or what ?

It concerne only a few WU but on the 3 computers on wich your project is running !

Please let me know .

Please let the WUs finish. The progress bar issue is a visual glitch only, and doesn't make the WUs invalid. However, it only shows up for large WUs, so expect them to take longer. Hopefully a new app version will be out soon to fix it - the fix itself is very simple.

Hi,
I have some Mikyway's WU that are calculate to more than 100% .
So I canceled them !
Should I let them go or what ?

It concerne only a few WU but on the 3 computers on wich your project is running !

Please let me know .

There is other topics about this in the "Number Crunching" section. It seems to be just an error with the % calculation.

---

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

Thanks for the quick answer !

Why don't you just fix the BOINC bug that allows a host to always have the full quota with only 2% valid results?

void SCHEDULER_REPLY::got_good_result() {
    host.max_results_day *= 2;
    if (host.max_results_day > config.daily_result_quota) {
        host.max_results_day = config.daily_result_quota;
    }
}

void SCHEDULER_REPLY::got_bad_result() {
    host.max_results_day -= 1;
    if (host.max_results_day < 1) {
        host.max_results_day = 1;
    }
}

would better be

void SCHEDULER_REPLY::got_good_result() {
    host.max_results_day += 1;
    if (host.max_results_day > config.daily_result_quota) {
        host.max_results_day = config.daily_result_quota;
    }
}

void SCHEDULER_REPLY::got_bad_result() {
    host.max_results_day /= 2;
    if (host.max_results_day < 1) {
        host.max_results_day = 1;
    }
}

The only problem would be that other BOINC bug, that applies only to a few projects : WUs that are cancelled on server side reduce the host quota instead of beeing quota-neutral.

I'd also like to put a note out there to people running scripts to cancel WUs from certain searches, asking you to stop. These can lead to some bad server problems where some WUs accumulate on the server because they're not being processed fast enough. We'll be taking some steps on the server end to stop this kind of activity, but until that gets finished I'd like to ask people to stop. If it continues I'll start banning or zeroing out offending users credit. --Travis

What, people running scripts on this project? Say it isn't so. Ban 'em!

---

me@rescam.org

I don't get why someone would cancel a WU? Do they have a favorite section of the galaxy?

At the moment the different types of WUs have different runtimes, yet still give the same credit. So if you want the most credit, you'd cancel all the longer running WUs. Of course, this is very bad for the project.

Hi Travis,

i agree with Misfit, ban those j***s from the project. I have never even considered to cancel a wu because of what reason ever there may be. If you are interested in more credits, then simply leave your machines crunching the whole night.

Greetings from Germany,
Christopher

Aborting tasks is soooo yesterday! One needs to write a script to weed out those pesky long runners, even worse, one risks getting banned! Running SP apps, that's the way to go! No scripting, no sanctions, 4x+ the credits!

---