It seems the RAM problem is not yet solved. I just updated Rosetta now and got the same complaint about needing 6 GB of RAM and only having 3 GB.

It's not a problem, it's just some tasks needing more RAM.

It is a problem when a Work Unit says it it will need 6+GB of RAM, when it really only needs 300MB (or less), as that results in almost a third of the projects computing resources becoming unavailable.

It's true all the ones that came through to my larger machines all say under 700MB RAM. Maybe they can occasionally need a lot more so they're playing safe and not crashing small machines with them?

[snip]

I allocate 28Gb from 32Gb total
They don't need the RAM. If they run, they generally use 300Mb, not 5 or 6Gb each. It's more than a bit crackers

Anyway, new news. I grabbed another few tasks while WCG is mainly running and they all seems new and running normally without crashing.
I think the hint dropped pretty heavily when every task got sent back un-run.
Things are happening whether they say so here or not

Have you considered the possibility that many of those creating workunits are not yet very good at estimating how much RAM they will need to run?

I suspect that many of them are also not yet very good at reading the task log files, recognizing the problems they show, and correcting them.

Hello. After approx. 15 years with Baker Lab, I've experienced an interesting problem, under the general category, computer errors.
Sorry to copy the entire err. report, but perhaps it will clarify.

Any ideas? The past three downloads gave, basically, the same results. Unless computing requirements have changed, recently, then I'll
have to change. Otherwise, perhaps, UW's end is with some new problems?

Good luck.

Jim Martin


Task 1364797245


Name ajzjTxIe_YBAABB_ABYBB_AAAAAAXB_AAY_CGGGGGGCCGGGGGCGGGGGGGGCGGGC_1-4_2-5_3-6.pdb_0001_abinitio_1_abinitio_SAVE_ALL_OUT_1389656_916_1
Workunit 1220204735
Created 7 Apr 2021, 15:30:32 UTC
Sent 7 Apr 2021, 15:32:35 UTC
Report deadline 10 Apr 2021, 15:32:35 UTC
Received 7 Apr 2021, 17:59:51 UTC
Server state Over
Outcome Computation error
Client state Compute error
Exit status 1 (0x00000001) Unknown error code
Computer ID 1324493
Run time 39 sec
CPU time 24 sec
Validate state Invalid
Credit 0.00
Device peak FLOPS 3.37 GFLOPS
Application version Rosetta v4.20
windows_x86_64
Peak working set size 153.00 MB
Peak swap size 124.98 MB
Peak disk usage 0.01 MB

Stderr output
<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 -fragA 00001.500.6mers -fragB 00001.500.4mers -in:file:fasta 00001.fasta -abinitio::increase_cycles 10 -mute all -abinitio::fastrelax -relax::default_repeats 15 -abinitio::rsd_wt_helix 0.5 -abinitio::rsd_wt_loop 0.5 -abinitio::use_filters false -ex1 -ex2aro -in:file:boinc_wu_zip cp_ajzjTxIe_YBAABB_ABYBB_AAAAAAXB_AAY_CGGGGGGCCGGGGGCGGGGGGGGCGGGC_1-4_2-5_3-6.pdb_0001_abinitio_1_fold_data.zip -out:file:silent default.out -silent_gz -in:file:native 00001.pdb -out:file:silent_struct_type binary -detect_disulf true -fix_disulf disulf -constraints::cst_file CB_cst -constraints:cst_weight 1 -number_9mer_frags 150 -number_3mer_frags 150 -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 1985841
Using database: database_357d5d93529_n_methylminirosetta_database

ERROR: ERROR: FragmentIO: could not open file 00001.500.6mers
ERROR:: Exit from: ......srccorefragmentFragmentIO.cc line: 233
BOINC:: Error reading and gzipping output datafile: default.out
11:41:18 (10892): called boinc_finish(1)

</stderr_txt>
]]>

---

perhaps, UW's end is with some new problems?

Yes: many people have reported the same issue recently. There’s nothing we can do about it other than let the bad work units fail, or stop running Rosetta until the problem has passed.

When I was a teenager,

If you're THAT old, you shouldn't be getting hot flashes every time someone says "dude."

There’s nothing we can do about it

We could ritualistically sacrifice a chicken, and then sprinkle its blood and entrails on @Peter Hucker.

The best part is, none of the staff of the nursing home would believe that it happened, when it's reported by the other residents.

It seems the RAM problem is not yet solved. I just updated Rosetta now and got the same complaint about needing 6 GB of RAM and only having 3 GB.

It's not a problem, it's just some tasks needing more RAM.

It is a problem when a Work Unit says it it will need 6+GB of RAM, when it really only needs 300MB (or less), as that results in almost a third of the projects computing resources becoming unavailable.

It's true all the ones that came through to my larger machines all say under 700MB RAM. Maybe they can occasionally need a lot more so they're playing safe and not crashing small machines with them?

I allocate 28Gb from 32Gb total
They don't need the RAM. If they run, they generally use 300Mb, not 5 or 6Gb each. It's more than a bit crackers

Anyway, new news. I grabbed another few tasks while WCG is mainly running and they all seems new and running normally without crashing.
I think the hint dropped pretty heavily when every task got sent back un-run.
Things are happening whether they say so here or not

Have you considered the possibility that many of those creating work-units are not yet very good at estimating how much RAM they will need to run?

I suspect that many of them are also not yet very good at reading the task log files, recognizing the problems they show, and correcting them.

I hadn't considered it because if someone can code for the kind of work we're getting I wouldn't be so grossly insulting as to suggest they're a bit thick.
I can easily imagine either the slip of a finger or maybe some kind of test that they didn't want to be limited by RAM or disk space to have accidentally been left in.

Honestly, of all the things to suggest... have a word with yourself

Aside from that, it would be nice if we could have a few more of those tasks that it seems I was lucky to pick up. They seem fine on my main PC with plenty of RAM

Edit again: Miraculously picked up 4 tasks on my laptop immediately after posting. None again when I tried on the desktop. They're trying, but hand to mouth.

---

Thanks, for the reply, Brian. I wonder why some have this problem, and others don't. Nothing has changed (computer) on this end of the line.
So, will just run SiDock@home, for awhile. Natalia has a cheerful, and informative approach to running things.

jm

---

Hello. After approx. 15 years with Baker Lab, I've experienced an interesting problem, under the general category, computer errors.
Sorry to copy the entire err. report, but perhaps it will clarify.

Any ideas? The past three downloads gave, basically, the same results. Unless computing requirements have changed, recently, then I'll
have to change. Otherwise, perhaps, UW's end is with some new problems?

[snip]

This line seems to be the important one:

ERROR: ERROR: FragmentIO: could not open file 00001.500.6mers

I've seen such errors in most of my recent failed tasks from R@H, so it is probably an error in what was included in the workunit.

[snip]

Have you considered the possibility that many of those creating work-units are not yet very good at estimating how much RAM they will need to run?

I suspect that many of them are also not yet very good at reading the task log files, recognizing the problems they show, and correcting them.

I hadn't considered it because if someone can code for the kind of work we're getting I wouldn't be so grossly insulting as to suggest they're a bit thick.
I can easily imagine either the slip of a finger or maybe some kind of test that they didn't want to be limited by RAM or disk space to have accidentally been left in.

Honestly, of all the things to suggest... have a word with yourself

Aside from that, it would be nice if we could have a few more of those tasks that it seems I was lucky to pick up. They seem fine on my main PC with plenty of RAM

Edit again: Miraculously picked up 4 tasks on my laptop immediately after posting. None again when I tried on the desktop. They're trying, but hand to mouth.

You appear to be assuming that those who write the code for the application are the same ones creating the workunits.

They have to be taught at some time. Which activity do you think they are allowed to do first? Or do you think that they can start both at the same time, with no tests of what the are doing works properly?

Name ajzjTxIe_YBAABB_ABYBB_AAAAAAXB_AAY_CGGGGGGCCGGGGGCGGGGGGGGCGGGC_1-4_2-5_3-6.pdb_0001_abinitio_1_abinitio_SAVE_ALL_OUT_1389656_916_1

It seems to be the work units that have names that look like someone fell asleep at the keyboard
or a tin o fizzy stuff gon sticky keys that are the worst
with over 800 of the whack job units in my Error list,
that's is a lot of duff guff to clog up the data base and turn it into more of a septic tank.

Name ajzjTxIe_YBAABB_ABYBB_AAAAAAXB_AAY_CGGGGGGCCGGGGGCGGGGGGGGCGGGC_1-4_2-5_3-6.pdb_0001_abinitio_1_abinitio_SAVE_ALL_OUT_1389656_916_1

It seems to be the work units that have names that look like someone fell asleep at the keyboard
or a tin o fizzy stuff gon sticky keys that are the worst
with over 800 of the whack job units in my Error list,
that's is a lot of duff guff to clog up the data base and turn it into more of a septic tank.

Hopefully it means something to someone somewhere.

Have you considered the possibility that many of those creating work-units are not yet very good at estimating how much RAM they will need to run?

I suspect that many of them are also not yet very good at reading the task log files, recognizing the problems they show, and correcting them.

I hadn't considered it because if someone can code for the kind of work we're getting I wouldn't be so grossly insulting as to suggest they're a bit thick.
I can easily imagine either the slip of a finger or maybe some kind of test that they didn't want to be limited by RAM or disk space to have accidentally been left in.

Honestly, of all the things to suggest... have a word with yourself

Aside from that, it would be nice if we could have a few more of those tasks that it seems I was lucky to pick up. They seem fine on my main PC with plenty of RAM

Edit again: Miraculously picked up 4 tasks on my laptop immediately after posting. None again when I tried on the desktop. They're trying, but hand to mouth.

You appear to be assuming that those who write the code for the application are the same ones creating the workunits.

They have to be taught at some time. Which activity do you think they are allowed to do first? Or do you think that they can start both at the same time, with no tests of what the are doing works properly?

Christ...

---

Hopefully it means something to someone somewhere.

Ah: divided by a common language… :-⁠)
Perfectly comprehensible this side of the pond.

tin o[f] fizzy stuff = can of soda
duff = defective
guff = nonsense

Also “septic tank” is occasionally used as rhyming slang for “Yank”, but I don’t think that’s what’s meant here.

You appear to be assuming that those who write the code for the application are the same ones creating the workunits.

I hope they work on the same office/building.....or that they keep in touch constantly!

Or do you think that they can start both at the same time, with no tests of what the are doing works properly?

Ralph@home exists for that.

---

will just run SiDock@home, for awhile. Natalia has a cheerful, and informative approach to running things.

Yeah – it’s a new project: they’re still keen. I dare say it was like that here in the early days, too? And that 15 years from now users will be moaning that the SiDock admins don’t talk to them any more…

And that 15 years from now users will be moaning that the SiDock admins don’t talk to them any more…

There are "old" projects that have active admins on forums.

---

My linux client appears to be stuck with issues with messaging from the server.
I removed Rosetta and added it back.
I'm not getting any work untis.
It says ...

Requesting new tasks from CPU
Scheduler requests complete: got 0 tasks
No tasks sent
Project requested delay of 31s

After the 31 seconds, no further requests are made
Manual requests reruns the loop

I've uninstalled the program, rebooted etc...

---

I'm not getting any work untis.

Neither is anybody else. There is no work that needs doing at the moment. Try again in a couple of days’ time.

I'm getting new work. My larger x64 machines are only getting 11 per request so it takes a few goes to get enough for all cores.

On the Pi4 4GB I'm still getting;
Rosetta@home 9/04/2021 9:16:50 AM Message from server: Rosetta needs 6675.72 MB RAM but only 3460.72 MB is available for use.

The 6.6GB free memory requirement hasn't changed.

---

MarksRpiCluster

Hopefully it means something to someone somewhere.

Ah: divided by a common language… :-⁠)
Perfectly comprehensible this side of the pond.

tin o[f] fizzy stuff = can of soda
duff = defective
guff = nonsense

Also “septic tank” is occasionally used as rhyming slang for “Yank”, but I don’t think that’s what’s meant here.

Lol! Too much information.

Wrt whether that's what was meant, I didn't think it was wrt the slang. I thought it was wrt to the CGCCGGG stuff in the task names

Isn't that genetic code? I've assumed it was. Whether it is or not, it's only important it means something to them, not to us.

Unless they're too dumb to understand what they're naming means - far be it for me to exclude all possibilities...

---