I have two 3970X machines. FWIW, I find that MT tasks run ~2x faster under linux than Windows. My guess is that it has something to do with the way the OS keeps MT tasks assigned to the chiplets. I think linux is just better at it.

Thank you.
All posted now, and I've got my first Mega. :-)

Of all the projects I'v taken part in on Boinc et al, PG is OUTSTANDING in its ability to allow interaction with the database, and involvement in searching the data relationships etc.

I take my hat off to volunteers, and designers who have created and maintained it. Thanks.

Hi RFGuy_KCCO,

Just curious if the preferences setting "Max # of simultaneous PrimeGrid tasks" would help limit the number of tasks downloaded to your computers even though you are using an app_config file. If you figure out how many concurrent tasks your highest core-count machine on a certain venue uses, then add 1 or 2 to that and set the "Max # of simultaneous PrimeGrid tasks" preferences to that value, it may alleviate the issue caused by BOINC here. You will still download some extra tasks, but it will be severely limited. The addition of 1 or 2 to the maximum allows tasks to be downloaded before they are needed, to avoid any delays between tasks.

If you haven't tried it; it may be worth a try.

And aborted tasks really aren't a problem. There is an observation bias which makes someone more likely to notice when they receive the task generated to replace the aborted task, but in the end aborted tasks will benefit the wingman exactly 50% of the time and disadvantage the wingman exactly 50% of the time. For every aborted task there is someone who received the companion task at the same time who now has extra time to crunch it and someone who receives the aborted task who now has less time to crunch it. You're just much more likely to notice the second case :)

Regards,
Kellen

I wouldn't need to abort so many tasks if BOINC would behave. Even with my cache set to 0 days, every one of my rigs still downloaded 400+ WUs and BOINC is keeping the cache that full all the time. Why does it do this? Is it because I use an app_config to limit my running task threads to be equal to the number of actual cores, so half of the logical processors available?

What's the problem with aborting tasks anyway? Don't they just go back in the queue for others to pick up and crunch? I am not sorting through them to find ones where I am the first cruncher; I abort everything.

By the way, when this challenge is over, I will have several thousand tasks to abort, thanks to BOINC's bad behavior. Just giving you a heads up. I hope no one has a meltdown because of it.

The Bad Behavior is 99% on you and not on BOINC's
I get NO Extra Tasks to run setting the two items below and do not have to Abort hundreds of Tasks over and over as you seem to do to often.
You are now over 13610 Aborted Tasks. I am just saying is all.

Set to 0

Set to 0

BAM! if used