Duplicate post deleted.

You'd think there'd be a delete button. Who designs these things?

There's a workaround. If you use the same way to mark it as a duplicate every time, the software will see it as multiple identical posts, and delete all but one of them.

Shouldn't it have already done that when the 2nd genuine one was posted?

Yes. But it's rather slow to happen.

So why would this way be any faster?

---

This is unsustainable and I will either have to shell out for an expensive unlimited contract (because I have an Ultima connection at over 100mbps) or cut back on Rosetta work.

I'm guessing you don't have any real options when it comes to ISP? 50GB limit for a 100Mb connection is insane IMHO. Higher speed plans here come with high data caps.
50GB is something you used to get on a basic 25Mb/s starter plan- these days even 12Mb/s plans have can have as much as 500MB data caps. 100Mb/s plans are 1TB caps or unlimited by default (of course we pay through the nose for those).

Wow. In the UK there's no data cap whatsoever. I can download at 54Mbps 24/7.

---

But it would be nice of the researchers would test their models a bit more before releasing them here. The odd error is OK, but when it's a case of the odd Task not being an error and all others erroring out it really is a bit silly.

There's Ralph@home for that. Not sure why they hardly ever use it. I think I get tasks from there once every 3 months.

---

That means nothing. For example I might (manually or Boinc did it) download a load of work from another project when this one runs out. Now that has to be completed before it will get work from Rosetta again.

It really is a shame you don't read all of what's posted before you feel the need to comment.

You said "Looks like the amount of work being done has dropped by almost a third, and isn't showing any signs of recovering." which is a false assumption. It could take a while. My computers for example haven't tried to get more Rosetta since it ran out, since they got stuff from other projects.

Who is the guilty party submitting tasks that all "Error while computing"? I have 70 tasks on April 4th that have errored with no credit.

That would be you.

I assume he meant which scientist....

you have a big appendage.

I'm...um, "flattered" that you think about that, but just for the record, I don't roll that way. Kindly limit yourself to policing my vernacular, dawg.

Bigot!

That means nothing. For example I might (manually or Boinc did it) download a load of work from another project when this one runs out. Now that has to be completed before it will get work from Rosetta again.

It really is a shame you don't read all of what's posted before you feel the need to comment.

You said "Looks like the amount of work being done has dropped by almost a third, and isn't showing any signs of recovering." which is a false assumption. It could take a while. My computers for example haven't tried to get more Rosetta since it ran out, since they got stuff from other projects.

And i'll repeat it again- It really is a shame you don't read all of what's posted before you feel the need to comment.
I addressed the point you made in the post that i quoted when i made that statement.


Regardless of caches & resource share settings & people's micro-management of their projects- if you compare the graph of the current recovery with past recoveries after a lack of work over the same recovery time frame, the loss of almost 1/3 of the processing resources is quite obvious.
The mis-configured Work Units are making it impossible for a large number of host to do any work (and that batch of Tasks that produced nothing but errors in a matter of seconds didn't help things along either).

Current recovery (or lack of) after almost 3 days.



Previous recovery (after a much longer outage) after 3 days.

---

Grant
Darwin NT

not error at all here, no computer with the 6GB requirement of Ram ...

Duplicate post deleted.

You'd think there'd be a delete button. Who designs these things?

There's a workaround. If you use the same way to mark it as a duplicate every time, the software will see it as multiple identical posts, and delete all but one of them.

Shouldn't it have already done that when the 2nd genuine one was posted?

Yes. But it's rather slow to happen.

So why would this way be any faster?

I didn't say it would be faster. However, it will give users less to waste their time reading.

Say hello to two less hosts after they finish their current tasks, @Rosetta. I don't know if I have the time that's required to provide the space that is needed.

You’re not alone. Look at the recent results graphs – ‘tasks in progress’ has dropped by around 200,000 (a third)…

In the past it has taken several days for In progress numbers to get back to their pre-work shortage numbers. And that's with out running out of work again only a few hours after new work started coming through (which occurred this time).
If we don't run out of work again over the next few days, we should see how things actually are by early next week.

A few days in and the impact of the mis-configured Work Units is becoming clearer. Looks like the amount of work being done has dropped by almost a third, and isn't showing any signs of recovering.
For all of the latest & greatest systems there are, there are an awful lot more older much more resource limited systems.

Returning to my anecdote about a remote PC I have being unable to download any Rosetta tasks, so running its backup project, WCG, 24/7, my local laptop is also doing weird things. It refuses to run a particular Rosetta task, so it's running those it has room for - a combination of WCG and later Rosetta tasks, but only 3 on 4 cores. Now I know it's definitely happening, I've set NNT and suspended all running tasks except for the one problem Rosetta task. It still refuses to run, even as the only task. No tasks are running in my experiment!

So, maintaining NNT, I've found some combination of WCG and Rosetta tasks that'll run together on all 4 cores. I'll work my way through my small cache until all are completed bar the problem task and see if it runs then. If not, I'll finally abort it and just grab fresh tasks.

Bit of a weird one. Even attempting to micromanage tasks doesn't entirely work. No wonder that graph is running so much lower than it was, if I'm any example

---

Has there been a significant project change which could be the cause of this increased usage or am I looking for another problem?

Hard to say.
In most cases the results returned to the Rosetta servers are around 200k-1MB. But they can be well over 1MB in some cases, depending on the type of Task being processed.
I'd suggest disabling BOINC network access for a while & see what the average result file size being returned is.

Edit- and as Brian mentioned, we have recently had a large batch of Tasks that error out quickly, and appear to still be moving through the system.

I haven't mentioned this because I'm doing some experiments with overclocking and I thought the errors were being caused by me. So it was everyone? Interesting to know.

In the last day or so, these computation errors appear to have stopped. Can others confirm that too?
Hopefully that stops all the re-downloading issues and bandwidth penalties.
Is it stopping the excessive memory & disk space demands too?

And now I notice queued jobs have plummeted to barely more than 100k. Hmm...

---

Thanks to all for their views. I confirm the fairly low 50gb cap vs 100mbps circuit is due to an old tariff. It is no longer available but the ISP cannot remove it easily because of the regulator. All new users or changers automatically have unlimited but at a substantially higher monthly cost which I am trying to avoid because the cap has been adequate for years. I do not stream, peer or otherwise have need for substantial throughput.
I have followed the advice for run time and have changed the preferences from the default 8 hrs to 22 hrs and will see whether that helps. I confirm that it is the three threadrippers which wireshark identified straight away as the hoggers - every other endpoint line was low mb's. Presumably if the 'bad' tasks work through or are withdrawn this will also help.
jsm

Good idea to increase the runtime, but be aware that the tasks you already hold in your cache will run for much longer than Boinc realises, so it's entirely possible/probable you won't meet deadline on the later ones.

If my memory serves me, the unstarted tasks will still show they're 8hrs long, but will actually run for your new preference of 22hrs. This runtime figure for unstarted tasks doesn't update so it will be a permanent problem.
The way around this is to reduce your cache size by around two-thirds, so even though it continues to show Boinc the wrong expected runtime, you won't exceed deadlines in practice.
You may've already noticed this on your threadrippers. Crazy as it seems, the solution I've described ought to prevent the problems I've pointed to.
It's a feature rather than a bug... <cough>

---

[snip]

In the last day or so, these computation errors appear to have stopped. Can others confirm that too?
Hopefully that stops all the re-downloading issues and bandwidth penalties.
Is it stopping the excessive memory & disk space demands too?

And now I notice queued jobs have plummeted to barely more than 100k. Hmm...

The computation errors due to problems with 6mers have stopped.

I didn't see those other errors, so I can't tell if they have stopped.

weird thing, just got a resend but not sure to finish it !

https://boinc.bakerlab.org/rosetta/workunit.php?wuid=1217325166

This issue was discussed recently in another thread.

The work unit got resent because the first machine hadn’t completed it by its deadline. But 10 minutes later – after you’d started the resend but before you’d finished it – the other host submitted its results. I think you’ll still get credit if you complete it before the deadline, but from the science perspective there’s no point because the results are already in.

with a 10GB boinc disk space setting, Boinc still send weird messages like this one

04-Apr-2021 15:13:03 [Rosetta@home] Rosetta needs 6675.72 MB RAM but only 4060.49 MB is available for use.
04-Apr-2021 15:21:01 [Rosetta@home] Rosetta needs 252.21MB more disk space. You currently have 8330.86 MB available and it needs 8583.07 MB.

and nothing was downloaded ...

i have to reset the project and this message is gone away, and now Boinc is downloading tasks again . . .

even the first message of lack of memory gone too for this moment ..

Haha , they're back
.

04-Apr-2021 15:57:48 [Rosetta@home] Sending scheduler request: To fetch work.
04-Apr-2021 15:57:48 [Rosetta@home] Requesting new tasks for CPU
04-Apr-2021 15:57:51 [Rosetta@home] Scheduler request completed: got 0 new tasks
04-Apr-2021 15:57:51 [Rosetta@home] No tasks sent
04-Apr-2021 15:57:51 [Rosetta@home] Rosetta needs 6675.72 MB RAM but only 4060.49 MB is available for use.
04-Apr-2021 15:57:51 [Rosetta@home] Rosetta needs 134.84MB more disk space. You currently have 8448.22 MB available and it needs 8583.07 MB.
04-Apr-2021 15:57:51 [Rosetta@home] Project requested delay of 31 seconds
04-Apr-2021 15:57:56 [Rosetta@home] General prefs: from Rosetta@home (last modified 04-Apr-2021 15:30:57)
04-Apr-2021 15:57:56 [Rosetta@home] Computer location: home
04-Apr-2021 15:57:56 [---] General prefs: using separate prefs for home
04-Apr-2021 15:57:56 [---] Preferences:
04-Apr-2021 15:57:56 [---] max memory usage when active: 4060.49 MB
04-Apr-2021 15:57:56 [---] max memory usage when idle: 4060.49 MB
04-Apr-2021 15:57:56 [---] max disk usage: 12.00 GB
04-Apr-2021 15:57:56 [---] (to change preferences, visit a project web site or select Preferences in the Manager)

This issue was discussed recently in another thread.

As well as claiming they needed 6.6 GB of RAM, the recent work units were configured to require 8.5 GB of disk space. With a preference setting maximum disk usage to 10 GB, and more than 1.5 GB already in use (around 2 GB is normal for R@h), the server was unable to send those tasks and so issued that warning.

Resetting the project didn’t make any difference because the disk space that freed up was immediately consumed again by the smaller tasks you were able to download.

Resetting the project didn’t make any difference because the disk space that freed up was immediately consumed again by the smaller tasks you were able to download.

Along with the executables & support data files.
Over time as different Tasks are downloaded, those support data files will be re-downloaded & the lack of disk space issue will re-occur (if the configuration issue for certain Work Units hasn't been fixed by then), as you soon found out.


Since the project is out of work again, other than the odd resend, now no one will be able to get any new work.
Hopefully the next batches of work system requirements will be configured more appropriately.

---

Grant
Darwin NT

A new batch of work has been loaded up- hopefully these have their requirements set properly, and they won't error out in a matter of seconds either.

---

Grant
Darwin NT