OK

But I can update SIDOCK and get this message, and then immediately update one of the other projects and get work

Sigh

The best multicore processing possible from the point of view of computational efficiency is X independent tasks that are processed independently in their own single-threaded process. As it is now(and from the start) implemented in SiDock and many(most of) other BOINC projects.
Parallelism is provided at the data level and can be efficiently scaled to any available number of cores/threads without additional efforts.

No multi-threaded application can surpass it, at best it only can come pretty close to it.

The only significant drawback of the "X independent tasks running on each of the CPU cores" approach vs MP-app is a much higher consumption of RAM.
But since specifically in SiDock the RAM usage is quite low (usually under 200 MB per running process), then SiDock does not really need any MP applications at all.

And all the available resources/time of developers is much better and more useful instead, to let them complete the development of the GPU application of CmDock. Which has been in the works for more than two years now. And which they promise to "finish soon" (last such "soon" was about 8 months ago), but so far they have not been able to finish it.

Dear participants,

as target # 22 is almost finished, we are glad to introduce the next target. Most of you have voted for Ebolavirus glycoprotein (GP) (174 out of 425 votes, wow!)

We hope that our computations will contribute to the fight against Ebola!

The WUs that are running should complete soon and I’ll confirm when they do.

This is good news! Thank you for notice!

The next 6 WUs have all finished clean in just over 24 hours with several more about to finish. Happy days :-)

The newer 2.02 units seem to be completing ok, one puzzle that remains is inconsistent granted credit, in some cases a variation of up to 25% for the same computer.

https://www.sidock.si/sidock/workunit.php?wuid=49667156
https://www.sidock.si/sidock/workunit.php?wuid=49667239

I have just restarted my secondary pc after a year’s absence and I’m seeing many WUs crashing with the above exit code, mostly after a few seconds. (So far no WUs have successfully completed but a couple are running ok).

The system is a Ryzen 9 3900 with 16gb ram and 256gb nvme running Ubuntu 22.04 and Boinc 7.18.1.

My first guess is memory, maybe fuzz on the connectors but I thought I’d ask if anyone had had similar problems?

At least it's not 10 credit; not what you'd expect for 309k sec but over 1k.

Ryzen 3900X @ 4.0 GHz got 1004.96 CS for 85211.20 seconds of computations or 1004.95 CS / 23.67 hours / 4.0 GHz = 10.61 CS/(hour*GHz).
i5-8250U @ 1.60GHz got 1129.15 CS for 298826.10 seconds of computations or 1129.15 CS / 83.01 hours / 1.60 GHz = 8.50 CS/(hour*GHz).

But SMT of Ryzens much more efficient than Hyper-Threading of Intel.

Is multithreaded planned here?

Multithreaded tasks would be wonderful for the long WUs. I only ever crunch one project at a time so between multithreading and keeping a smaller cache, deadline issues would quickly become a thing of the past.

Yes, I did that. The long tasks are too long.

When I try to do it from "Tools>Add Project" directly I get a message that "The URL you supplied is not that of a BOINC-based project".

I had been running SiDock on one of my laptops (NOT this computer) but inadvertently removed it. Now I cannot find it in the list to add it back as a project. How can I do that?

Project reset with no new work units instructed based on the number of them hanging.

On to another project until this issue is resolved.

Dear Participants,

TMPRSS2 is a type II transmembrane protease with broad expression in epithelial cells of the respiratory and gastrointestinal human tracts. It is a cofactor in SARS-CoV-2 entry, and primes viral proteins. Namely, TMPRSS2 cleaves the viral Spro to expose the fusion peptide for cell entry. We are therefore examining TMPRSS2 as a promising strategy to block viral infection in a host-directed therapeutic and/or prophylactic manner. This work is also a a part of larger viral-host protease inhibition study campaign.

With best wishes,
Team SiDock@home

Mine are running almost 6 hours on a Ryzen 3950X (Ubuntu 20.04.3).
The last batch was only about 30 minutes.

I am new to this project and had only the short w/u so far. 2 w/u per thread makes more sense now. My processing went fro 50mins or so to 10+ hrs.
All well then
Nairb

...
Personally i prefer to set the maximum concurrent running task by reducing the % o CPU and leaving CPU time at 100%
For example on your i3-4030u (4t) you can set % of CPUs between 50 and 74% to run 2wus, 75 to 99% to run 3wu
...

Yes, reducing number of concurrent tasks may be better solution than percent of CPU time.

Indeed - this is not a Sidock problem, it happens with many projects. Boinc put this option in which doesn't work, or relies on something most projects don't use.

снова не получает задания, теперь пишет постоянно
15.03.2022 23:12:51 | | [network_status] status: don't need connection

Due to the community request, we also plan to add official Mac and ARM64 support for the underlying CmDock software.

Great news! Thanks!

I'd definitely be interested in seeing some graphs of how much processing power was there before the poll and now :)

Hello! :)

Before: ~ 18000 tasks in progress.
Now: ~23000 tasks in progress.