At the expense of thermally stressing the CPU which does not happen if you use less cores for 100% of the time.

That will have a bigger impact on the throughput (tasks completed per day). A 10% drop in CPU use on all cores is all I need on my older machines to get temps I'm happy with. Taking 1 core away from 4 is the same as a 25% CPU use reduction. I prefer having the finer control of %cpu available.

Unless its causing WU crashes, it really helps with controlling heat issues on some rigs while still using all cores.


Use at most x% of cpu time should be removed from boinc source code

The priority is to get the replacement EAS25 batches out (for aborted 1002-1004) once the troublesome files have been corrected and tested. It's highly likely they will be using the new WaH2 app which has been in development & tested not to suffer from the excessive failures. It has already been added to the main site as v8.29 of the WAH2 Region Independent app (or wah2-ri for short). If you receive a workunit for wah2-ri 8.29, you're running the new app. George (aka geophi) noted in testing the new app is ~10% faster than the old one.

It's been done this way so as not to interfere with currently running wah2 workunits. There is also a new linux version of wah2-ri which is currently in test (not on the main site yet).

The OpenIFS batch is ready & has been tested, but I'm not happy with some of the failures coming from the monitor code (not the model). To be discussed.

The HadAM4 I think is about ready, maybe needs bit more testing.

So, alot of Windows & Linux work coming soon.

I'll be able to confirm more next week after the usual Monday CPDN meeting.

HTH

Copied from old thread from Glen.

Forthcoming batches

The following batches are planned for Jan (or early Feb).

a/ Weather@Home (Windows)*

NZ25 - New Zealand 25km grid, natural forcings.
EAS25 - East Asia 25km grid, range of different forcings.


b/ HadAM4 (Linux)
N216 climatological runs producing high frequency northern-hemisphere output.

c/ OpeniFS (Linux)
Low resolution batch to look at variation of model results across different hardware

*We'll also roll out updated versions of the apps for Weather@Home, HadAM4, & HadSM4 to fix issues with the models failing, particularly on restarts. Although we hope to get these out before the Weather@Home batches it may not happen due to time pressure from the projects funding these batches.

Hoping some of these might come sooner rather than later but I have given up holding my breath!

Presumably the _bl is waiting for memory fetch or disk io a lot more than the _ps which is happily sitting in loops computing and racking up the flops.

Nothing to do with memory nor IO. As I said previously they are two very different model configurations. The 'BL' app is running an idealised planet with no land, so all the land surface process code in the model does not run. The PS app is a normal model forecast but with perturbed parameters which potentially gives a different execution time for each individual forecast.

Confirmation from Andy@CPDN that the export of credit is working again.

Boincstats seems confused, it says I haven't changed position in the last day/week/month, and I've received no credits, but I know I have. I was 583rd before the stats stopped exporting, now I'm 520th.

Doesn't bother me really as I just note the positions on my own graph.

Hopefully now I can run Windows or Linux tasks, I can plough ahead soon.

If some extra credit is awarded accidentally, is that a bad thing really? There have been plenty of times where credit are lost accidentally, right?

I had a 24 core per region quota limit, though I've not tried to raise it. I was able to just create some 4/8/22 core VMs and they're purring away nicely.

Rosetta@Home is out of tasks, though there are still some retries going around.

I suppose next steps to run out of work would be Folding@Home CPU or maybe Einstein@Home, though I don't particularly find pulsars/neutron stars/etc particularly interesting projects, and certainly not of much "Earthly importance."

Which applications exactly are the "region independent tasks?"
I keep getting hadam4 WUs and I sure do NOT want to waste my electric bill on useless garbage.
If there's obsolete WUs circulating then the project should issue "server aborts" for all of them and clear the decks of the flotsam and jetsam.

I'll mention it and see what response I get, credit is actually quite a pain for a project to have to manage from what I've learnt.

Returning valid results for the researchers to analyze is the important matter, credit is a 'nice to have'. Others may think otherwise, but I won't mind if the credit update is rare or doesn't happen.

I tend to agree. For myself, credit is more about another tool to spot problems than anything else. But I get that for some it is a motivating factor.

Some kind of accounting of work done both in relative and absolute measure is important I'd argue. I have little doubt that at one point or another everyone looked at their credit and standings even if to just get an idea of the level of contribution over time. It's pretty normal behavior and I have no doubt that everyone would be asking for some way of knowing of how much one's contributed if there was no such measure provided at all. I agree that complicated credit system is unnecessary and a weekly credit run is fine. Unlike other projects, on CPDN task counts don't get erased from when you first join so you can actually tell how many tasks you've processed and calculate your error rate long term. I think that's kind of a nice thing. Although a cluttered and somewhat uninformative Project Status page is the trade-off, is my guess. Badges might be nice as they'll provide incentive to likely many people. Although, I'd rather see a number of other things improved first before concerning with badges.

Well, I probably should have debugged this first. <work_fetch_debug> did the trick and this likely has nothing to do with version. For the top priority project that was picked, I saw this repeatedly showing up in every fetch cycle.

[work_fetch] deferring work fetch; upload active

I was able to observe the same issue happening with LHC when it's slowly uploading after a batch of tasks finish. Turns out if the current project picked for fetching is constantly uploading, the fetch will just be deferred and boinc won't try the next project. It's the right behavior if we assume upload should be quick, but sometimes uploading is going to take forever... Guess I need to build up a job cache big enough for the entire period of uploads just in case the project uploading ends up getting picked for fetching.

Okay, here is the next failed WU and I ask again, why has this WU failed: https://www.cpdn.org/result.php?resultid=22268795

I'm seeing not stderr out.
That's quite strange.

BOINC is showing its weekly increase in credit from CPDN today. If not showing on BOINCSTATS, I wonder if CPDN have changed something so BOINCSTATS is looking in the wrong place or the page where it looks hasn't been updated for some reason. If it looks like that is the case I will email Andy.