I agree Joe. MCM is going out, but at about half rate. I've been asking for MCM for a few hours, but I haven't gotten one yet.

MCM now showing no tasks available.

Mike

I think part of the "shortage" of MCM is due to some of the work units being of a shorter duration. I have not noticed it on my Windows machine, but have noticed it on my two Linux machines, On one of them units which normally take about 3 to 3.25 hours are taking 1 to 1.5 hours. On the slower machine, it is normally about 4 to 4.25 hours and some of the work units are running about 3 to 3.25 hours.
I am curious to see if anyone else has seen this behavior.

Edit: I did a quick preliminary check of the average time per work unit from August 6 to the present (the last 90 days). Back on August 8, the average time per work unit was just around 2.00 hours. This has deceased a bit to an average of about 1.98 hours. This doesn't seem like a big difference(it amounts to about 72 seconds per work unit). This could be a change in the makeup of the work units, or it could be a change in the mix of machines which are doing the crunching.

If there has been no change in the Windows crunching, there would be little effect on the total efficiency because if I remember correctly from a long time ago, Windows makes up about 80% of the crunchers, with Linux being a little less than about 20% with the remainder being Apple, Darwin and other variants. This may have changed a bit over the years, but I haven't seen anything recent.

I would welcome any corrections.

Cheers

Edit:spelling

Shorter duration? Was that associated with limited availability??

Above a certain [system dependent] level, the more BOINC CPU threads active, the slower the tasks are likely to run (though I don't know how true that is of server-type CPUs and systems); ... For some applications the slowdown can be attributed to them becoming memory-bound, but I suspect that for MCM1 it is more likely to reflect the total amount of power available to the CPUs :-)

As I have limited "spare" power at my property(!) some of my systems spend most of their time sitting at a maximum power limit I have chosen and others have a frequency cap applied to achieve the same effect. When MCM1 work was difficult to acquire over the last few days the power-capped systems could suddenly run MCM1 tasks up to 30% faster. (And ARP1 tasks got a similar boost, because with only one at a time there was no real risk of memory access issues!)

Another reason for dramatic changes in run-time is 32-bit versus 64-bit tasks (though that wouldn't cause a decrease in run-time!) -- I occasionally get a retry for a WU that started life on 32-bit systems, and the MCM1 variety tends to take between 25% and 50% longer to run depending on the parameters for the specific WU. However, I haven't seen many (if any) 32-bit tasks recently.

Of course, if/when we change back to work on the other target that was interrupted to revisit Ovarian Cancer data the run times will get a lot higher again :-)

With apologies if all the above is "old news"...

Cheers - Al.

P.S. Subject to the variability of run times caused by higher clock rates, I haven't noticed any obvious signs of shorter (or longer) tasks; there's often a variability of a few percent depending on the complexity of the iterations as against the number of iterations, but akin to the small differences Sgt. Joe quoted in his edit, not the large ones :-)

[Edited to add the P.S. and rephrase some other stuff as a result.]