CPU tasks.

Yes, exactly.

In the message pointed to by the first link in my post, I did describe the machine as an old quad core iMac owned by my daughter.  It's actually around 2011 vintage.  iMacs are slow anyway and old iMacs are very slow so I wasn't trying to claim any sort of performance crown :-).  I was trying to point out the 3:1 ratio in overall times due to different data files.  There's something wrong if a more modern machine can't well and truly beat those numbers.  Independent of the age of the machine, there should still be a similar 3:1 ratio with different data.

Tom needs to stop blaming his wisdom file or his CPU for that big change.  I'd be surprised if a wisdom file could give more than something like a 10% - 15% improvement, if that.  Years ago, when the project first made the app for creating wisdom files available, I was running lots of CPU tasks and I spent time creating these files for a range of different architectures.  If I remember correctly, the average improvement I saw was around 3-5% or something like that.

Gary,

I have read the posts you have made.  I am not ignoring them. I am not talking about them either which may be why you think I was ignoring them.

I appreciate your thoroughness and postings on variations in CPU processing time.  And I clearly over stated "The Wisdom file trick strikes again" phrase. 

I am reasonably confident the Wisdom file can account for maybe a 10% variation in my baselines.  And I didn't take that into account when I posted what you are reacting to.

It is clear that the differences in data have a massive effect on processing time.  I have NOT been tracking the specific tasks.

For some reason my 3950x box with Amd specific ram has been processing more than twice as fast as my 2700/3900x box.  Since prices are pretty reasonable I am going to drop that variable out of the mix by matching ram in both boxes (already have same MB). 

That leaves the variables of task Data, OS, OS compilers, cpu ipc/architecture differences between the 3950x and the 2700/3900x in play.

I have been assuming a "random" selection of tasks.  What you are telling me is the tasks are distributed in a much more "clumpy" way.  Which would skew my observed results :(

Your analysis of the tasks makes it clear that if I wanted to get a more specific estimate I would need to match specific task series id #'s for both machines.

I apologize for giving you the impression I was ignoring your posts.

Tom M

ps. Once I have the faster ram and later the cpu in place I will follow the protocol (bump the cache size) to get some comparable "before/after" results tasks so I can "see" differences.

So, it looks like Einstein is handing out 1041F and 1046F now. However, I was able to get numbers on four more 1045F tasks which vary between 10 hours and 48 minutes, to 10 hours and 50 minutes. Based on this small sample, wisdom saves about an hour and ten minutes of crunch time for the same power consumption figures. Rounding to the nearest minute, and averaging, I'm seeing about a 10 percent reduction in crunch time. I would prefer to have a larger size sample, but these numbers don't seem unreasonable. Again. others might see different numbers based on their configurations and CPUs.

The tasks list for that box (at the time I looked) had 8147 entries of which 6110 show as 'error' - that's over 300 pages of errors.  I looked at a few of the most recent pages and all I saw was wall-to-wall aborts.  Aborting a task is regarded as an error.  Your daily allowance is reduced according to the number of 'errors'.  It gets increased again by returning completed tasks.

With so many recent 'errors' it's a wonder the server will send you any tasks at all.

No you don't have to do that.  If you allow the CPU tasks to crunch and be returned without any more aborts, your full allowance will be restored and you will start getting GPU tasks.  The best way to prevent excess CPU tasks is to set a small cache size and then you can stop aborting.

Your current problem is quite likely due to excessive cache size for the 'current conditions', coupled with your propensity to abort CPU tasks as a 'solution'.  Aborting tasks while the cache size is high might temporarily solve the issue but it's bound to return again at some point unless you lower your cache size.  This will be particularly nasty if the client doesn't 'know' the true crunch time for the new tasks it is requesting.  Below is a simple calculation to show what might have happened to create your current 'problem'.  This is just conjecture because you don't give any details - even basic ones like what size work cache are you setting and are you fiddling that up and down?

As you should now be aware, there are GRP CPU tasks that have crunch times in a 3:1 ratio, depending on which particular data file is in play.  Let's assume a 5 day cache size and you are crunching the 'fast' tasks.  You have lots of tasks (5 days worth) but no problem because the deadline is 14 days.

A change in data file happens and you start getting 'slow' tasks.  Your BOINC client cannot know about this for another 5 days when the first of the 'slow' tasks reaches the top of the queue and gets crunched.  The outcome of the first slow task being crunched will be a three times longer estimate for all tasks on board and this will send the client into a panic since the new three times longer estimate will now represent 15 days worth of work.  The client will think this even if you only got a couple of slow tasks and then started getting fast tasks again.  One slow task (even a resend) is enough to send the estimate through the roof.  You need a large number of fast tasks to bring that estimate back down again.

Another factor adding to this is that GPU tasks crunch faster than the estimate.  With a single duration correction factor (DCF), GPU tasks will cause the estimates for CPU tasks to be lowered and your client will request more CPU work.

You can easily counteract all of this by keeping your cache size low.  If you set 1 day maximum and let BOINC control things, you will never have excess CPU tasks and you will never need to abort any of them.

You can set a compute preference (either on the website or locally in BOINC Manager) that says, "use at most 'blank'% of the processors" and set 'blank' to be whatever percentage you want.  There are other more complicated ways by using app_config.xml files (not cc_config.xml).  You have 32 threads.  If you wanted BOINC to use half of those, just set 50%.

Changing that preference will not solve the current problem.  If you set 50%, BOINC would only download half the number of CPU tasks and with half the threads able to crunch them, what can possibly change?  Absolutely nothing!  BOINC will still get into the same panic if fast crunching tasks change to slow and, many days later, BOINC suddenly becomes aware of the change.  If you had a 1 day cache setting, the tasks on hand could only ever grow to 3 days worth, due to the 3:1 crunch time ratio and BOINC would easily cope with that.

You just need to set a suitable cache size for your system and the conditions under which you are running it.

I'm sorry, but you can't have been.

Your tasks list on the website shows CPU tasks take between about 3 to around 9 hours or more on your machine - the 3:1 ratio, no doubt, for different data files.  Let's assume BOINC thinks that every task will take 3 hours.  A 0.25 day cache for 32 cores is just 64 tasks for tasks taking 3 hrs.  It's even less if a task takes longer.  Currently you have around 230 CPU tasks, so how do you explain that?  And that's not counting the more than 6000 error tasks.  Your client must have asked for those somehow.

So what is BOINC currently estimating that a CPU task will take??  To justify 230 tasks for a 0.25 day cache, BOINC would have to be thinking that a task will take around 50 mins.  It would be even less if the client knew it wasn't using the full 32 cores.  You have 2 GPUs so surely the client knows it can't use the full 32 cores??

The project doesn't send work unless the client asks for it.  To get the 6000 odd tasks that show as errors - many of which you downloaded and aborted, either you had a large cache size or the client had an incredibly low estimate of how long a CPU task would take to crunch.  You need to pay more attention to what is going on since nobody else can see this sort of information that you alone see.