There was quite a conversation a while back about those transient errors. Someone found that if the line
128.95.160.156 boinc-files.bakerlab.org
is included in the /etc/hosts file that things work better. I don't know if it's still needed or not, I haven't removed it.

---

There was quite a conversation a while back about those transient errors. Someone found that if the line
128.95.160.156 boinc-files.bakerlab.org
is included in the /etc/hosts file that things work better. I don't know if it's still needed or not, I haven't removed it.

Thanks, it is working for me too

---

Matthias

Does this mean that the processed data can be uploaded again soon and that there will soon be new work?
My Boinc can't get rid of the work for rosetta@home and the new work can't seem to be downloaded.
It would be nice if it could continue again soon.

I finally got 11 Rosetta tasks, three of which were almost immediately rejected as Errors While Computing.

They were all Rosetta Beta v6.06
windows_x86_64

S. Gaber

Does this mean that the processed data can be uploaded again soon and that there will soon be new work?
My Boinc can't get rid of the work for rosetta@home and the new work can't seem to be downloaded.
It would be nice if it could continue again soon.

I finally got 11 Rosetta tasks, three of which were almost immediately rejected as Errors While Computing.

They were all Rosetta Beta v6.06
windows_x86_64

S. Gaber

The latest update reads:

January 4, 2025
Update from the data centre: "Having issues with the physical network , likely can't get it diagnosed and fixed until Monday, January 6.". As a result - we still do not have a connection to our servers.

It is now Tuesday January 7 morning, and still nothing.

Now :-

January 7, 2025
Networking issues have been resolved. The data centre staff is finalizing our access.

Since then:

January 8, 2025
Most of our infrastructure is back online. Unfortunately, some issues with the network and specific virtual machines remain. Thus, the BOINC database node remains unavailable, and the website and forums also do not function properly.
Sharcnet data center team is working on to restore access to these instances in priority order.
Once this is resolved, we will have a smooth restart of the workunit management and BOINC components on the backend, and be able to isolate and diagnose any remaining issues as we restart.

And finally

January 9, 2025
BOINC database is up and in a good state. We are waiting on two more servers to regain access to the network, at which point we will be restarting the scheduler, transitioner, assimilators and validators.
All deadlines for outstanding MCM1 work units have been extended to just after 6:00 p.m. Eastern Standard Time on January 15th, 2025.
Web site is up; stats will be updated soon.
Forums are up.

One hour ago I got 50 new tasks, which have struggled down with everyone piling in, but after several retries I succeded.
Hoping for a period of normality

---

There was quite a conversation a while back about those transient errors. Someone found that if the line
128.95.160.156 boinc-files.bakerlab.org
is included in the /etc/hosts file that things work better. I don't know if it's still needed or not, I haven't removed it.

That remedy worked for me too.
It took immediate effect after editing hosts file, no need to restart compuer, nor BOIC Manager.
Thank you very much!

January 9, 2025
BOINC database is up and in a good state. We are waiting on two more servers to regain access to the network, at which point we will be restarting the scheduler, transitioner, assimilators and validators.
All deadlines for outstanding MCM1 work units have been extended to just after 6:00 p.m. Eastern Standard Time on January 15th, 2025.
Web site is up; stats will be updated soon.
Forums are up.

One hour ago I got 50 new tasks, which have struggled down with everyone piling in, but after several retries I succeded.
Hoping for a period of normality

And a final housekeeping update

January 10, 2025
All our servers are back online. We are downloding processed work units and sending out new ones, and they have the right deadlines (after the initial glitch with the time).
We have noticed 92,194 results that ended up in an error state. We saved all these in a file so we can repair this issue. We'll be able to rescue these, especially since there is no file deleter or db purge daemon running for now, so all data related to these workunits is still on the filesystem.
We will continue to monitor the system to make sure it is stable.
We are also working on getting MAM project into beta.
Thank you all for continuing to support research. Happy new year.

---

We are also working on getting MAM project into beta.
Thank you all for continuing to support research. Happy new year.

What is MAM??

---

Mapping Arthritis Markers.

Mapping Arthritis Markers.

Interesting!!

---

It's Wednesday.
And the servers are down.

As usual

---

It's Wednesday.
And the servers are down.

Just the usual one.

---

Grant
Darwin NT

It's Wednesday.
And the servers are down.

Just the usual one.

Not sure when, but boinc-server is back and some tasks keep sneaking through even though I never see any stock available on the server page or front page.
Luck of the draw if you see any.

---

There was quite a conversation a while back about those transient errors. Someone found that if the line
128.95.160.156 boinc-files.bakerlab.org
is included in the /etc/hosts file that things work better. I don't know if it's still needed or not, I haven't removed it.

That remedy worked for me too.
It took immediate effect after editing hosts file, no need to restart compuer, nor BOIC Manager.
Thank you very much!

This also worked for me on Ubuntu. Thank you!

With some of the recent robetta tasks, single decoys are running for 5 or 6 hours, so tasks are running short of the 8hr default.
With my 12hr runtime my tasks are either running just over 6hrs, with a few completing 2 decoys in about 10.5hrs.
Not ideal, but it is what it is.

---

With some of the recent robetta tasks, single decoys are running for 5 or 6 hours, so tasks are running short of the 8hr default.
With my 12hr runtime my tasks are either running just over 6hrs, with a few completing 2 decoys in about 10.5hrs.
Not ideal, but it is what it is.

I have 4hrs as default running time
Now I have some wu over 11hrs.
Big decoys!!

---

2 decoys

OK, I'll bite. What's a "decoy"? I've seen that term used around here in my results, something I seldom look at.

---

I have found this: https://foldit.fandom.com/wiki/Decoy

I have found this: https://foldit.fandom.com/wiki/Decoy

That's most likely the correct answer.
But I used the term in line with what's shown in the Stderr output of the task detail like here to discover what was making the task to run short.
At one time they accidentally imposed a maximum decoy limit which caused the task to terminate when it was reached (very short time for each decoy).
The decoy limit was quickly corrected, but sometimes those corrections get undone in a new batch of work.
But as it turned out in this case it was that the time for each decoy was too long, not very short.
The current rb tasks are running fine - 27 decoys and a full 12hrs for me again.
More a simple comment than a complaint.

---

It's Wednesday.
And the servers are down.

As usual

It's Wednesday. Again.

---