"The queued stacks of WUs tend to be systems where they have, say, 12 cores, download 24 WUs but then only allow 2 WUs to run concurrently alongside their other projects."


As to this statement, yes true. It is not about allowing two WU's to run "concurrently" alongside other projects. It is all about how many cores you can run at an ambient temperature of 45c without melting the machine down. In the afternoon I can run only two cores( nothing to do with projects). At night, maybe four. Vector in GPU computing also.
Another factor is the base speed. At all twelve cores running simultaneously, maybe 2.2 MHz. A single core. 4.04 MHz. I am still thinking about the advantages of so many cores. Maybe getting WU's of Climate. Should I get a forty-eight cores machine? Naaa, that is a bit of being silly.

You can of course control the size of your buffer. Setting it to the default of 0.1+0.5 days will get you fewer work units than setting it to 10 days, for example. But that is rather crude, and sometimes they won't send you anything at all.

Unfortunately, the BOINC scheduler is not aware of the "app_config.xml" file, so if you set it to run only two work units, it will still download as if you were running on all 12 cores. So until BOINC gets smarter (a long process), the best way would be for CPDN to provide you a user-selectable limit of how many work units you want downloaded at a time. Several projects do that now: WCG, LHC and Cosmology that I can think of at the moment.

But CPDN has been going in the direction of fewer options. They need to reverse course.

Better would be CPDN slashing drastically the due back date and then re-issuing the WU"s. The current due back date is from the time of Pentium One. I know, it used to take ages then. Now with faster RAM, SSD drives and modernisation, maybe five days to complete.
As to the buffer size, my GPU is busy on another project whose WU"s it completes in four minutes flat. I earn my credits with my GPU and CPU's are full time dedicated to Climate.

Better would be CPDN slashing drastically the due back date and then re-issuing the WU"s. The current due back date is from the time of Pentium One. I know, it used to take ages then. Now with faster RAM, SSD drives and modernisation, maybe five days to complete.

Yes, even on a slow machine like my current desktop that is going to end up like the axe that has been in my family for generations. (Grandfather gave it a new head, father a new handle) tasks complete in 31/32 days max. (Pentium(R) Dual-Core CPU E5400 @ 2.70GHz) Next upgrade will be new CPU memory and motherboard which with PSU and hard disks having been changed already will only leave the case as original.

Another advantage for machines who have dedicated their CPU's to Climate, their machines hammer at the server every one and a half hours or so. Their requests I suppose get lined up, maybe justice. Machines which have not dedicated their CPU's to Boinc and if even there is work available (their work quota might be full of letting us say Collatz WU's) Boinc will not ask the server for work. If you check the server state now and then, there are about 22 or 24 machines dedicated. The rest are busy.

Is batch 871 still open? I just received 2 Wu’s (both _2s). They have failed on 2 other machines. They must be 3 or 4 months old. Are they still needed an wanted.

---

Is batch 871 still open? I just received 2 Wu’s (both _2s). They have failed on 2 other machines. They must be 3 or 4 months old. Are they still needed an wanted.

Batch 871 is still open. It was issued on May 22nd 2020.

It is rare for batches to be closed under nine months or even a year except when withdrawn because of a major problem that should have been caught in testing when a new batch is subsequently issued.

I can only remember two or three instances o this happening but might well have missed some.

Thanks. Hopefully I can shepard these two along and get them completed.

---

Oops! Just picked up two retreads when I was trying to clear laptop of work prior to doing a clean install of 20.04 - Thought I had put all projects to no new tasks. - Obviously not!

Dave -

What did you do? Upgrade to 20.04 without a clean install? Your computers show you have 20.04 on both computers and the tasks downloaded today.

I upgraded to 20.04 from 18.04 without any problems on several computers as soon as 20.04 became available (actually before as a beta). without any issues.

.

---

What did you do? Upgrade to 20.04 without a clean install? Your computers show you have 20.04 on both computers and the tasks downloaded today.

Yes, did a standard upgrade via the command line. However this stopped the manager from working though not the client due to some wxwidgets conflict. This also causes make command to fall over when I roll my own manager on the laptop though not the desktop. I have found a work around with Jord's self extracting manager and client for the laptop to get it going again. Now I just have a longer wait till I can clean things up.

What did you do? Upgrade to 20.04 without a clean install? Your computers show you have 20.04 on both computers and the tasks downloaded today.

Yes, did a standard upgrade via the command line. However this stopped the manager from working though not the client due to some wxwidgets conflict. This also causes make command to fall over when I roll my own manager on the laptop though not the desktop. I have found a work around with Jord's self extracting manager and client for the laptop to get it going again. Now I just have a longer wait till I can clean things up.

FYI, you can open a terminal and issue commands to start/stop/enable/disable the BIONC client before and after upgrades:

sudo systemctl start boinc-client
sudo systemctl stop boinc-client
sudo systemctl disable boinc-client
sudo systemctl enable boinc-client

You can also use the BOINC command line interface to manage the the client. See:

man boinccmd

You can also use the BOINC command line interface to manage the the client. See:

Yes I was managing BOINC from the command line until I got a work around. However I like to play and often build my own BOINC client and manager from source code using the testing versions and would quite like to get back into being able to do that on the laptop.

You can also use the BOINC command line interface to manage the the client. See:

Yes I was managing BOINC from the command line until I got a work around. However I like to play and often build my own BOINC client and manager from source code using the testing versions and would quite like to get back into being able to do that on the laptop.

Yes, yes boinccmd has been a great help to me over the years when the gui fails, as it does from time to time.
But I don't think many users even imagine how useful a cli interface can be.
My daughter asked me a few months ago, while taking a coding class --"dad, how do I get out of less?" "q".
How few CPDN volunteers even know what differential equation is?

How to get more crunchers?
Then there will be more work units.

---

So I got excited and configured one of my machines to do the new N216 models. When it didn't get any work I thought "Oh well, gone already." Then I realized I had issue commands to the wrong system and it didn't get any work because it's queue was full. Oops. Once I had the right IP address for boinccmd I got 4 of the new 5 month models. I'll try to have them back within 14 days but I can't promise because I have never run 4 N216's on one Zen2 chiplet. I was able to do three 4 months WU's in 7-8 days though so it shouldn't be that bad.

It looks like the 5 month WU's are running at 10% a day on the 3700X. It would be a little faster if I was only doing 3 of them but it's still a good rate.

And now all gone bar the inevitable retreads.

Still no news as to when they might make the main site but more testing is happening with the OpenIFS tasks.

If the latest batch is anything to go by, they will not be for everyone, the ones I ran recently peaked at 11GB of RAM and about 13GB of swap. (I never saw my swap file usage go up to anything like that so I wonder if that means data swapped out to disk in the BOINC data directory though usage there never got up that high when I looked.

OpenIFS v2.19
x86_64-pc-linux-gnu
Peak working set size 11,797.17 MB
Peak swap size 13,131.91 MB
Peak disk usage 3,516.51 MB

I would have to resize my virtual memory for those then. Currently only 8GB.

Yes, these are classed as high resolution.