I don't know how FAH got ahold of my CPU, maybe after an update or something.
Anyway it's eliminated from CPU now.
Thanks for the reminder.

I don't know how FAH got ahold of my CPU, maybe after an update or something.
Anyway it's eliminated from CPU now.

<core_client_version>7.16.16</core_client_version>
<![CDATA[
<stderr_txt>
command: ../../projects/boinc.bakerlab.org_rosetta/rosetta_4.20_arm-android-linux-gnu -run:protocol jd2_scripting -parser:protocol pre_helix_boinc_v1.xml @helix_design.flags -in:file:silent pre_helical_bundles_round1_attempt1_SAVE_ALL_OUT_IGNORE_THE_REST_6nr4xe1m.silent -in:file:silent_struct_type binary -silent_gz -mute all -silent_read_through_errors true -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip pre_helical_bundles_round1_attempt1_SAVE_ALL_OUT_IGNORE_THE_REST_6nr4xe1m.zip @pre_helical_bundles_round1_attempt1_SAVE_ALL_OUT_IGNORE_THE_REST_6nr4xe1m.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 3400220
Extracting in project directory: database_357d5d93529_n_methyl.zip
Using database: database_357d5d93529_n_methyl/minirosetta_database

ERROR: [ERROR] Unable to open constraints file: f9b5372889da3e02c19de86d067b31e6_0001.MSAcst
ERROR:: Exit from: src/core/scoring/constraints/ConstraintIO.cc line: 457
 called boinc_finish(0)

</stderr_txt>
]]>

<core_client_version>7.16.11</core_client_version>
<![CDATA[
<message>
Incorrect function.
 (0x1) - exit code 1 (0x1)</message>
<stderr_txt>
command: projects/boinc.bakerlab.org_rosetta/rosetta_4.20_windows_x86_64.exe -run:protocol jd2_scripting -parser:protocol pre_helix_boinc_v1.xml @helix_design.flags -in:file:silent pre_helical_bundles_round1_attempt1_SAVE_ALL_OUT_IGNORE_THE_REST_2ke5kf4f.silent -in:file:silent_struct_type binary -silent_gz -mute all -silent_read_through_errors true -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip pre_helical_bundles_round1_attempt1_SAVE_ALL_OUT_IGNORE_THE_REST_2ke5kf4f.zip @pre_helical_bundles_round1_attempt1_SAVE_ALL_OUT_IGNORE_THE_REST_2ke5kf4f.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 1087567
Using database: database_357d5d93529_n_methylminirosetta_database

ERROR: [ERROR] Unable to open constraints file: f5d52c1749a40719598f1d8b37e13c45_0001.MSAcst
ERROR:: Exit from: ......srccorescoringconstraintsConstraintIO.cc line: 457
BOINC:: Error reading and gzipping output datafile: default.out
10:42:25 (29468): called boinc_finish(1)

</stderr_txt>
]]>

I've being getting quite a lot of these errors on all my devices. Sometimes they get validated, sometimes they just result in a computational error.

Funny to note that my Snapdragon 888 is beating my Ryzen 5 3600 and gets much more consistent credits per task. My phone is getting around 394 credits for every 8hr task it gets, My Ryzen 5 3600 gets a measly 346 credits per 8 hour task. Either something is up with the credit calculation, or there is something about these pre_helical_bundles_round1_attempt1_SAVE_ALL_OUT_IGNORE_THE_REST tasks that make them particularly good on ARM. I'm leaning towards the former explanation because: 1) the benchmarks for my phone are 5887.99 million ops/sec floating point speed and 29296.86 million ops/sec integer speed , whilst my 3600 gets 5198.63 million ops/sec floating point speed and 19515.05 million ops/sec integer speed. 2) My 3600 seems to be consistently generating more "decoys" than my phone despite the credit deficit. Probably a BOINC issue that's been beaten to death already.

It's important to note that in the helical tasks, my 3600 actually appears to be doing more work (more decoys generated), it's just being granted less credits.

If there is actually a bug, do I want it to be fixed? Yes. Do I think it is an issue Rosetta should focus on? No.

[snip]

It's important to note that in the helical tasks, my 3600 actually appears to be doing more work (more decoys generated), it's just being granted less credits.

If there is actually a bug, do I want it to be fixed? Yes. Do I think it is an issue Rosetta should focus on? No.

Note that not all decoys do the same amount of work, so less credit per decoy is not necessarily meaningful.

[snip]

It's important to note that in the helical tasks, my 3600 actually appears to be doing more work (more decoys generated), it's just being granted less credits.

If there is actually a bug, do I want it to be fixed? Yes. Do I think it is an issue Rosetta should focus on? No.

Note that not all decoys do the same amount of work, so less credit per decoy is not necessarily meaningful.

And the benchmarks are used to determine the amount of work done (there is no actual measurement of work actually done as such...).
So systems with higher benchmark values get more Credit per hour than those with lower benchmark values (unless they are too much higher in which case it is determined they are cheating and Credit awarded becomes some sort of average based on all the work returned to date for such Tasks).
And that is why systems that haven't run the benchmarks and are using the default values get bugger all Credit for the work they return until such time as they eventually do run the benchmarks.

I assume these validate errors are also a known issue with the pre_helical_bundles_round1_attempt1_SAVE_ALL_OUT_IGNORE_THE_REST tasks

I've being getting quite a lot of these errors on all my devices. Sometimes they get validated, sometimes they just result in a computational error.

Those errors have been occurring with some pre_helical_bundles_ Tasks ever since they were released months ago.

I've finally got round to examining this issue involving "ERROR:: Exit from: ......srccorescoringconstraintsConstraintIO.cc line: 457"
I didn't realise I'd been getting this error as much as everyone else and I've now reported it, probably for the first time, which is likely why it's been going on for so long.
I thought there were two types of error resulting from this, but there are actually three.

The one you quote above gives a gzip error and reports in the task list as a Computation Error - boinc_finish(1) - and usually only has a cpu runtime of 15 seconds or less so awards no credit,
There's another with no gzip error that has a cpu runtime of 3 or 4 minutes and reports a Validate Error - boinc_finish(0) - and awards a few credits when the daily cleanup job runs
The third one also has no gzip error, has a runtime of only 6-9 minutes and reports as Completed and Validated correctly, but obviously doesn't run fully either.

My main PC is reporting 3 Computation errors, 3 Validate Errors and 50 Validating properly, but 2 of them are running short, so 8 of 56 have a problem - 1 in 7.
All bar 3 are awarding credit for runtime - and those 3 for less than a minute of cpu runtime in total across all 16 cores - so it's a far bigger issue for the project than it is for any user, and I've reported it as a project issue on that basis.

This is probably an issue for the BOINC board, but since I know you jamokes I will ask here first.

On one of my hosts, the BOINC manager will not launch. I try to run it as I have in the past, but nothing happens at all.

The host seems to be processing work, based on the CPU usage. But no joy with the manager program.

Any suggestions? I suppose that I can uninstall/reinstall; will that disturb anything?

This is probably an issue for the BOINC board, but since I know you jamokes I will ask here first.

On one of my hosts, the BOINC manager will not launch. I try to run it as I have in the past, but nothing happens at all.

The host seems to be processing work, based on the CPU usage. But no joy with the manager program.

Any suggestions? I suppose that I can uninstall/reinstall; will that disturb anything?

Look for a file in your home directory, 5 bytes long and called Boinc-Manager-xxx or similar. If you find it, delete it - it’s a lock file.

Look for a file in your home directory, 5 bytes long and called Boinc-Manager-xxx or similar. If you find it, delete it - it’s a lock file.