Quick question, out of interest. How many cores on your machines to you make available to CPDN/BOINC?

Another possibility, is that you're running Linux in a VM on a Windows machine.

I've found it best not to make life too complicated for a computer running climate models.

It looks like those tasks have already experienced 2 restarts. I'm guessing they errored out after a 3rd interruption. This has happened to me (interruptions were unintentional so it was very annoying).

I am on 7.20.1 and haven't had any problems. Which projects cause errors?

England has another possible explanation for why the IPCC models could be getting future La Niña-like conditions wrong. As the world warms and the Greenland ice sheet melts, its fresh cold water is expected to slow down a dominant conveyor belt of ocean currents: the Atlantic Meridional Overturning Circulation (AMOC). Scientists mostly agree that the AMOC current has slowed down in recent decades4, but don’t agree on why, or how much it will slow in future.

In a study published in Nature Climate Change on 6 June5, England and his colleagues model how an AMOC collapse would leave an excess of heat in the tropical South Atlantic, which would trigger a series of air-pressure changes that ultimately strengthen the Pacific trade winds. These winds push warm water to the west, thus creating more La Niña-like conditions. But England says that the current IPCC models don’t reflect this trend because they don’t include the complex interactions between ice-sheet melt, freshwater injections, ocean currents and atmospheric circulation. “We keep adding bells and whistles to these models. But we need to add in the ice sheets,” he says.

Michael Mann, a climatologist at Pennsylvania State University in State College, has also argued that climate change will both slow the AMOC and create more La Niña-like conditions. He says the study shows how these two factors can reinforce each other. Getting the models to better reflect what’s going on in the ocean, says Seager, “remains a very active research topic”.

These work units give 4 or 5 trickles, each about 25% apart.

I've got a shiny new pair of 3900Xs hanging out ready for real work to chew into, be it 32-bit Linux, 32-bit MacOS, or (dare I hope?) 64-bit!

I guess I could see if Folding@Home needs CPU cycles.

All BOINC clients communicate via the same port, 31416. One of them needs to be set to another port and I found that it's much easier to change the WSL2 client rather than Windows one (requires Registry edit). I assume you have standard BOINC installations in both WSL2 Ubuntu and Windows. Also just to note, you can only view and manage one client at a time in BOINC Manager not both at the same time. You'll have to switch between the two but that's easy to do which I'll describe at the end. You'll have to do some restarts during the process so you might want to wait until your current CPDN tasks are finished so they don't error out.

* Edit the following 2 files as follows.

1. Edit the configuration file for the boinc-client init script. Go to /etc/default and edit a file called boinc-client. At the bottom of the 7th paragraph add the following line. 51325 is an example port number, make up your own, I've seen it suggested that it be over 50000.

BOINC_OPTS="--gui_rpc_port 51325"

I hope cpdn actually comes up with some new work soon.

I run WCG ARP1 and MCM1 and they do clean up after finishing.

A note from Dave in the getting started area has the answer, these have been amended to be Mac only so we’re out of luck.

They don't crash, the last batch I checked were taking 12GB of RAM each and uploads were about 550MB Haven't tried to check on CPU cache but it hasn't been raised as an issue by other testers so I suspect not as much as the N216 tasks. Some batches have had final uploads of over 1GB so I have had them uploading while I sleep if on a day when I am doing any Zoom calls. Obviously not an issue for those with real broad as opposed to bored band.

I do not know what you call a CPU cache. I infer you refer to the part of your RAM that is currently devoted to that purpose.

In a normally running modern Linux, (almost) all RAM not used for something else is given over to the disk input cache. Anytime the kernel wants more RAM for a process, it can grab it from the disk input cache. If that is not enough, it can get it from the output buffer, but it would have to write it out first. And I suppose cachestat can tell you about that, but it is deprecated and not available for my distro. It seems to me that by the time you need a tool like that, you have long since passed the point where you seriously should increase the size of your RAM.

And my cache is supplying about half the requested memory references:

# perf stat -aB -e cache-references,cache-misses
^C
 Performance counter stats for 'system wide':

    33,364,888,278      cache-references                                            
    17,805,920,648      cache-misses              #   53.367 % of all cache refs    

      64.185688537 seconds time elapsed

I suppose the instructions are mostly in the cache, and very little of the data are in there.

$ sudo ./cachestat

Counting cache functions... Output every 1 seconds.
    HITS   MISSES  DIRTIES    RATIO   BUFFERS_MB   CACHE_MB
   18658        0       45   100.0%          139      36237
   57334        0       43   100.0%          139      36237
   30930        0       26   100.0%          139      36237
   21124        0       31   100.0%          139      36237
   92343        0      108   100.0%          139      36237
   26557        0       75   100.0%          139      36237
   25485        0       26   100.0%          139      36237
   97719        2       75   100.0%          139      36237
   21042        0       25   100.0%          139      36237
   38118        0       60   100.0%          139      36237
   46525        0       29   100.0%          139      36237
   25127        0       44   100.0%          139      36237
   98529        0       64   100.0%          139      36237
   25745        1       15   100.0%          139      36237
   23106        0       66   100.0%          139      36237
   92583        0       72   100.0%          139      36237
    8580        0       50   100.0%          139      36237
   38967        0       55   100.0%          139      36237
   64163        0       43   100.0%          139      36237
   25698        0       29   100.0%          139      36237
   86728        0       61   100.0%          139      36237
   24077        0       44   100.0%          139      36237
   21742        0       17   100.0%          139      36237
   77441        0       63   100.0%          139      36237
   26411        0       38   100.0%          139      36237
   18575        0       24   100.0%          139      36237
   85779        0       60   100.0%          139      36237
   29630        0       34   100.0%          139      36237
   41840        0       45   100.0%          139      36237
   30779        0       81   100.0%          139      36238
   35510        0       44   100.0%          139      36238
   98186        0      109   100.0%          139      36238
   20706        0       17   100.0%          139      36238
   16524        0        9   100.0%          139      36238
   72171        0       54   100.0%          139      36238
    1469        0       13   100.0%          139      36238
   43854        0       66   100.0%          140      36238
   52263        0       39   100.0%          140      36238