To be fair, Seti tasks could have a million year deadline and that would be too soon. Every minute they run is a waste of time.

I'm not agree with you. For example, it's thanks to Seti if Boinc platform exists.

P.S.
Now i'm crunching, at the end, wus for cpu...

---

I just tried attaching a Ubuntu machine again after a day off, and got the usual "Rosetta Mini for Android is not available for your type of computer". I get the sinking feeling that no one at the top is aware of the problem. But after they see the work falling off, they will call a committee meeting on what to do. Someone will suggest better PR, and they will implement a better "User of the Day" award.

The first number asks to maintain "at least" this much work, and the second number asks for "up to" this many days additional. Since some projects (like this one) run out of work on a irregular basis, I want a small supply to bridge the lack of supply. [Or you can think of it as an "occasional connection" to the supply]. Further, those numbers are for ALL projects (as I wrote in an earlier post) not just Rosetta. Today, SETI has maintenance and is offline for much or all of the day. My downloaded queue of WUs is being used to process during this period.

There is one wrinkle I have that few of the crunchers here have and that is that I am not in the U.S. I am in Vietnam, and three of the trans-Pacific internet cables are broken (see here if interested). Thus I AM connected only intermittently even though I would rather be continuously connected.

Oh! So it makes sense then. The rest of the arithmetic still applies though - a drawback while 2hr tasks are so plentiful. I guess 1 + 0.65 is the best you can use to avoid planning to fail to meet all deadlines.

---

Jim -- the project itself has run for over ten years with pretty solid reliability.

However, in terms of communications and responsiveness to end user reports and issues, they have been historically weak. It is an unfortunate aspect of the project.

It seems they really don't have anyone tasked to monitor the message boards including reports of problems. Further, no one is tasked to respond to end user reports including obvious reports which point to typically minor project configuration issues which could be corrected with just a bit of attention to the data provided by end users.

That, of course is exacerbated by the absolute lack of feedback to user community which provides those reports.

Now the reporting using community is but a VERY small number of the actual user population, so perhaps our efforts and feedback don't matter to the power that be, or at least don't matter enough to allocate a small amount of existing project resources to address the care and feeding of the most involved members of the Rosetta user community.

This is rather unfortunate.

As I noted before, I've now decided to pair WorldGrid with any workstation that has Rosetta. I've set World Grid with the same priority as Rosetta. So when Rosetta doesn't have work, or responds with its infamous automatic 24 hour back off, it amounts to the Rosetta project itself having a lower priority on my workstations -- and the WorldGrid folks who are also doing good research thus get a higher proportion of my processing time.

About a month ago, I had a Rosetta credit of 27 million. Today it is 27.7M

About a month ago, I had a Worldgrid credit of 17.5 million. Today it is 18.7 million. At this rate I figure WorldGrid will overtake Rosetta for me by the end of the year even though I have both projects at the same priority. I figure that's a project choice and am good with it.

Each project has their own internal priorities and it is apparent for Rosetta, that the care and feeding of their most interactive users is pretty low on their priority list.

I get the sinking feeling that no one at the top is aware of the problem. But after they see the work falling off, they will call a committee meeting on what to do. Someone will suggest better PR, and they will implement a better "User of the Day" award.

To be fair, Seti tasks could have a million year deadline and that would be too soon. Every minute they run is a waste of time.

I'm not agree with you. For example, it's thanks to Seti if Boinc platform exists.

Sure, credit for that, but don't milk that credit. The joke's long since over. I really do despise that project - the one thing that riles me up.

---

Jim -- the project itself has run for over ten years with pretty solid reliability.

However, in terms of communications and responsiveness to end user reports and issues, they have been historically weak. It is an unfortunate aspect of the project.

[snip a lot]

I reluctantly agree. I predict that until the server gets upgraded and is not stressed, and WUs start piling up unprocessed in the server, that no one at the project will care to improve the processing of the WUs.

Sad to admit, but I am an electrical engineer (retired) who graduated from the UW.

---

However, in terms of communications and responsiveness to end user reports and issues, they have been historically weak. It is an unfortunate aspect of the project........That, of course is exacerbated by the absolute lack of feedback to user community which provides those reports.

It's the same old story.
Is BakerLab interested in R@H or it's little more than a game?
If the answer is "R@H is very important for us", all it follows: investments on hardware and software update, more human resources on project (for example with a stable spokesman that reports from admins/devs to forum and viceversa), etc.
If the answer is "R@h is computational power for free", all it follows: no news, no admins, no updates/optimizations/etc.
Dekim is a good boy, but he is alone here....

---

Indeed, with the non-response from the project folks, at this juncture, I will process all work units I have on hand and set to no new work.

Sadly, it is not clear to me that the people running the project are even aware of the "Problems and technical issues with Rosetta@home" as they for whatever reasons have elected to isolate themselves almost completely from the reporting in the message boards.

So the lack of resolution of issues is significantly exacerbated by the project *choice* to not participate in any meaningful way with the user community, including those end users who take the extra time to participate on the message boards in the hope (not fulfilled) to get information to the project and in the hope (not fulfilled) to receive timely information from the project.

So I will monitor traffic here, but absent a change, the World Grid project which does good works is going to get my "CPU processing" vote with the available cycles.

I have participated in the Rosetta project for over ten years, so I do not make this choice lightly.

Is BakerLab interested in R@H or it's little more than a game?
If the answer is "R@H is very important for us", all it follows: investments on hardware and software update, more human resources on project (for example with a stable spokesman that reports from admins/devs to forum and viceversa), etc.
If the answer is "R@h is computational power for free", all it follows: no news, no admins, no updates/optimizations/etc.

It seems we are important for the project.
So, i hope some changes into the project's comunications with volunteers

---

Computing preferences:

Would someone please explain for me the logic behind 0+2? TIA

My preference is now set at 1.5+1. I increased it from 1.5+0.5 some time ago, as I was tired of running out of Rosetta tasks. Until this latest problem that worked well.

Yes, I occasionally get 2-day deadline tasks (sometimes as many as 10), and they defer tasks with 5-7 day deadlines for 6 hours or so (my chosen Target CPU run time), but since I have 8 cores they eventually all easily get processed in time.

---

@Darrell,

Thanks for the reply. Yes, the other projects and a fractional share of the time available would have that effect. As Sid points out, there is very likely a debt to R@h right now, and so in addition to short deadlines, you got a load of more work than average. It sounds like you are now to a point that even longer deadlines would reach the "running at high priority" state, because of the fractional resource share.

So another approach would be to clear the debts so they are all equal. That would help avoid BOINC requesting more work than the current cache window requires for any of your projects. At one time, there was a debt viewer tool which you could use to zero out the record of project debts. Appears you can now do it with boinccmd.

@mod.sense: I finally looked into doing that and found another description on the BOINC Wiki that seems to be 3 years newer.

<joke> Unfortunately, someone forgot to tell the developer to include it in the program. </joke>

When tried, I get the "help", not the results wanted. The "--set_debts" is not listed as valid even though the WIKI shows it.


Confirming the URL is valid:

S:Program FilesBOINC>boinccmd.exe --get_project_config https://boinc.bakerlab.org/rosetta/
poll status: operation in progress
poll status: operation in progress
uses_username: 0
name: rosetta@home
min_passwd_length: 6


Reset the debt for Rosetta:

S:Program FilesBOINC>boinccmd.exe --set_debts https://boinc.bakerlab.org/rosetta/ 0 0

usage: boinccmd [--host hostname] [--passwd passwd] [--unix_domain] command

default hostname: localhost
default password: contents of gui_rpc_auth.cfg
Commands:
--client_version show client version
--create_account URL email passwd name
--file_transfer URL filename op file transfer operation
op = retry | abort
--get_cc_status
--get_daily_xfer_history show network traffic history
--get_disk_usage show disk usage
--get_file_transfers show file transfers
--get_host_info
--get_message_count show largest message seqno
--get_messages [ seqno ] show messages > seqno
--get_notices [ seqno ] show notices > seqno
--get_project_config URL
--get_project_status show status of all attached projects
--get_proxy_settings
--get_simple_gui_info show status of projects and active tasks
--get_state show entire state
--get_tasks show tasks
--get_old_tasks show reported tasks from last 24 hours
--join_acct_mgr URL name passwd attach account manager
--lookup_account URL email passwd
--network_available retry deferred network communication
--project URL op project operation
op = reset | detach | update | suspend | resume | nomorework | allowmorework | detach_when_done | dont_detach_when_done
--project_attach URL auth attach to project
--quit tell client to exit
--quit_acct_mgr quit current account manager
--read_cc_config
--read_global_prefs_override
--run_benchmarks
--set_gpu_mode mode duration set GPU run mode for given duration
mode = always | auto | never
--set_host_info product_name
--set_network_mode mode duration set network mode for given duration
mode = always | auto | never
--set_proxy_settings
--set_run_mode mode duration set run mode for given duration
mode = always | auto | never
--task url task_name op task operation
op = suspend | resume | abort

S:Program FilesBOINC>

---

Sorry for that Darrell. Looks like it's been a moving target. Appears it is now something that can be done via the cc_config file.

<cc_config>
  <options>
    <zero_debts>1</zero_debts>
  </options>
</cc_config>

---

Rosetta Moderator: Mod.Sense

Sorry for that Darrell. Looks like it's been a moving target. Appears it is now something that can be done via the cc_config file.

<cc_config>
  <options>
    <zero_debts>1</zero_debts>
  </options>
</cc_config>

Ahh, thanks. I also see it is recommended to NOT use it starting with version 7. Oh well!

Do you know where the debts are stored so I could manually reset them? I am accustomed to editing potentially dangerous items (e.g., registry). Send me a PM if you don't want to post that information publicly.

---

The info. I saw was just that it was deprecated in v7. I also saw some info. about a new server-side figure that replaces debts. So, I'm really uncertain.

I had thought debts were stored in the client_state.xml but I don't see them there anymore.

I believe the other way to zero one project's debt would be to mark it for no new work, let it work through it's tasks and report them back, then detach and reattach. I believe as a "new" project is attached, it starts with zero debt.

---

Rosetta Moderator: Mod.Sense

The info. I saw was just that it was deprecated in v7. I also saw some info. about a new server-side figure that replaces debts. So, I'm really uncertain.

I had thought debts were stored in the client_state.xml but I don't see them there anymore.

I believe the other way to zero one project's debt would be to mark it for no new work, let it work through it's tasks and report them back, then detach and reattach. I believe as a "new" project is attached, it starts with zero debt.

The client doesn't use debts any more. Debt based scheduling was replaced by Recent Estimated Credit based scheduling. See Client scheduling policies and its design document Client scheduling changes (note that when the design document speaks of current it means the previous debt based scheduling). REC can be controlled with <rec_half_life_days>, shorter half life -> client has shorter memory.

But none of that matters here. When the client asks for more work it asks enough to fill the cache but not more than that.

Your answer is much appreciated. Thank you.

---

Stats are being picked up by the stats sites (eg Boincstats) but there's been no updates to the data. This has happened a few times since the site came back up a few weeks ago.

---

And of course for three weeks around the winter break as well.

Oh well

Stats are being picked up by the stats sites (eg Boincstats) but there's been no updates to the data. This has happened a few times since the site came back up a few weeks ago.

And of course for three weeks around the winter break as well.

Oh well

Stats are being picked up by the stats sites (eg Boincstats) but there's been no updates to the data. This has happened a few times since the site came back up a few weeks ago.

Yes. The missing days are shown here

Stats have been updated since I posted after 2 blank days for the 2nd time in the last week

---

And another blank day for stats

---