Whatever the problem is, i still think it's all to do with the problem we're having with the lack of work that's Ready to send.
These issues both seem to have occurred around the same time frame.

Millions of Tasks queued up to process, but none Ready to send, and the Assimilators not keeping up with the very minimal load they have at present.
It's all related to Rosetta's servers and their issues.


Looking at the graphs, you can see periods where the Assimilator backlog clears, and there are spurts of Tasks ready to send for an hour or so (although more likely it's for 10-20 min or less- the updating of the stats occurs vey infrequently. It needs to be every 5min or so to really see what is going on, not every hour or so).
And the Tasks In progress climbs for a while. Then it all falls over again.


It's been a week of these issues, and still nothing has been done to rectify it.

---

Grant
Darwin NT

Hi,
some config in ipv6 is wrong on their end.
You have to edit your hosts-file to use ipv4:

Linux: sudo nano /etc/hosts
Windows: notepad C:WindowsSystem32driversetchosts

paste these lines:

#Rosetta@home
128.95.160.156 boinc-files.bakerlab.org
128.95.160.156 bwsrv1.bakerlab.org

some config in ipv6 is wrong on their end.

It looks as if they haven't put in any IPv6 DNS entries for boinc-files.bakerlab.org, but have for some the other servers.

128.95.160.156 boinc-files.bakerlab.org
128.95.160.156 bwsrv1.bakerlab.org

What you have listed above for boinc-files doesn't match DNS, you may want to try removing (updating, or commenting out) that entry.

boinc.bakerlab.org
          2607:4000:406::160:156
          2607:4000:406::160:157
          128.95.160.156
          128.95.160.157

bwsrv1.bakerlab.org
          2607:4000:406::160:156
          128.95.160.156

bwsrv2.bakerlab.org
          2607:4000:406::160:157
          128.95.160.157

boinc-files.bakerlab.org
          128.95.160.134
          128.95.160.135

I know using DNS in the past hasn't always worked, I've even had to hard code the boinc-files IP in the hosts file to get things working, but I removed that a couple weeks ago, with no issues. For what it's worth, I'm not getting the error on any of my machines.

edit: grammar / dns entries

how to disable ipv6
https://networking.grok.lsu.edu/article.aspx?articleid=17573

For linux uncomment precedence ::ffff:0:0/96 100 in /etc/gai.conf This will make resolver prefer ipv4 addresses and connect to ipv6 address only if ipv4 address is not available.

Personally, I can only applaud the imagination and ingenuity of people who come up with workable solutions for the rest of us.

Well, this took off while I was at work...

---

Server Status and operating.

Server Status shows all servers are green. However, when we try to communicate with Rosetta, we are greeted with a message that the feeder is inactive.

We cannot upload or download WUs to the project, and relocated computers cannot add to the project.

Hopefully someone will have a good idea to get this excellent, and important, project back on track.

---

I have 45 tasks waiting to report for the last 4 days. There must be a problem with your sever which needs investigation.
[/img]

---

This workaround corrected the problem immediately. Thank you!

You have to edit your hosts-file to use ipv4:

Linux: sudo nano /etc/hosts
Windows: notepad C:WindowsSystem32driversetchosts

paste these lines:

#Rosetta@home
128.95.160.156 boinc-files.bakerlab.org
128.95.160.156 bwsrv1.bakerlab.org

Thank you. I already had the first line in there, but adding the second allowed the

Sat 29 Mar 2025 10:15:43 AM EDT | Rosetta@home | Reporting 42 completed tasks


reports to go up/

---

What you have listed above for boinc-files doesn't match DNS, you may want to try removing (updating, or commenting out) that entry.

There is no need to disable ipv6 at all, only these two Rosetta-Servers can be reached with ipv4 with these IPs.
It works only this way at the moment:

128.95.160.156 boinc-files.bakerlab.org
128.95.160.156 bwsrv1.bakerlab.org

Adding an ipv6-Entry (2607:4000:406::160:156 bwsrv1.bakerlab.org) will result in the same "feeder nor running"-Error.

There is no need to disable ipv6 at all, only these two Rosetta-Servers can be reached with ipv4 with these IPs.
It works only this way at the moment:

128.95.160.156 boinc-files.bakerlab.org
128.95.160.156 bwsrv1.bakerlab.org

I agree that you shouldn't have to disable ipv6, but the second part I don't agree with. I only have ipv4 internet connectivity, and set up a packet sniffer to see what R@H IP's my machines are connecting to. So far I've seen packets to/from .156, .157 and .134, uploading/downloading/updating, seem to use .156 and .157, and reporting seems to use .134 (hoping it uses .135 as well, but I've only had a couple WU to report complete since I started the capture, so not enough data yet).

Server Status and operating.

Server Status shows all servers are green. However, when we try to communicate with Rosetta, we are greeted with a message that the feeder is inactive.

We cannot upload or download WUs to the project, and relocated computers cannot add to the project.

Hopefully someone will have a good idea to get this excellent, and important, project back on track.

The only simple fast and dirty way to get back and running is to read the link I posted here https://boinc.bakerlab.org/rosetta/forum_thread.php?id=6893&postid=112334

The experts here are looking at other stuff.

You have to edit your hosts-file to use ipv4:

Linux: sudo nano /etc/hosts
Windows: notepad C:WindowsSystem32driversetchosts

paste these lines:

#Rosetta@home
128.95.160.156 boinc-files.bakerlab.org
128.95.160.156 bwsrv1.bakerlab.org

Thank you. I already had the first line in there, but adding the second allowed the

Sat 29 Mar 2025 10:15:43 AM EDT | Rosetta@home | Reporting 42 completed tasks


reports to go up/

Windows: notepad C:WindowsSystem32driversetchosts <--- huh? try breaking it down by directory. I got as far as drivers and then nothing matched.

Besides, why should we have to messing around with this kind of stuff?
RAH is supposed to be plug and play and none of this deep windows stuff.

There is no need to disable ipv6 at all, only these two Rosetta-Servers can be reached with ipv4 with these IPs.
It works only this way at the moment:

128.95.160.156 boinc-files.bakerlab.org
128.95.160.156 bwsrv1.bakerlab.org

I agree that you shouldn't have to disable ipv6, but the second part I don't agree with. I only have ipv4 internet connectivity, and set up a packet sniffer to see what R@H IP's my machines are connecting to. So far I've seen packets to/from .156, .157 and .134, uploading/downloading/updating, seem to use .156 and .157, and reporting seems to use .134 (hoping it uses .135 as well, but I've only had a couple WU to report complete since I started the capture, so not enough data yet).

ipv6 enabled gets the server error message. disabling it cures that unless someone has a easy and simple clear way of solving the inability of baker lab to keep their stuff in order.

ipv6 enabled gets the server error message. disabling it cures that unless someone has a easy and simple clear way of solving the inability of baker lab to keep their stuff in order.

Yeah, I get that. Doesn't matter as much why it isn't working [properly] vs what workarounds DO work. It just doesn't make sense why turning off ipv6 works, the hosts file entry should override DNS, so it should only try those ipv4 addresses and not even try ipv6.
The workaround sounds like only option for now (for those having the issue), until they have someone fix it. Smells of a DNS issue - or a misconfiguration, I think they need to have someone come in to check all the servers and networking, make sure everything is configured and running as needed.
Taking care of systems/networks like this is what I used to do, frustrating to not be able to fix things from the user side. If they needed help, I'd love to help (I'm sure many of us would). But from what I can see no one from the project is actually watching the forums, so...

But from what I can see no one from the project is actually watching the forums, so...

And they don't respond to emails.
This has been an issue for over a week, along with the lack of work Ready to send and the Assimilator backing up. And the download server issue? That's been over 6 months now.
And Ralph has been broken for around 9 or more months, and recently they just blocked it off (or something else broke).

Forbidden
You don't have permission to access this resource.

Is all you get when trying Ralph.

---

Grant
Darwin NT

C:WindowsSystem32driversetchosts - had back-slashes removed when posted (just tried)

C:|Windows|System32|drivers|etc|hosts - change | to back-slash

---

Paul.

But from what I can see no one from the project is actually watching the forums, so...

And they don't respond to emails.
This has been an issue for over a week, along with the lack of work Ready to send and the Assimilator backing up. And the download server issue? That's been over 6 months now.
And Ralph has been broken for around 9 or more months, and recently they just blocked it off (or something else broke).

Forbidden
You don't have permission to access this resource.

Is all you get when trying Ralph.

Grant - this has been the case since they stopped putting grad students on here and in turn started their focus on AI. That's where the money is. This project just gets stuff that does not fit the AI model.

I once emailed the secretary (?) about something here and that was a black hole.
You notice Dr. B does not even post here anymore.
So we are on our own to figure out solutions to their problems.

ipv6 enabled gets the server error message. disabling it cures that unless someone has a easy and simple clear way of solving the inability of baker lab to keep their stuff in order.

Yeah, I get that. Doesn't matter as much why it isn't working [properly] vs what workarounds DO work. It just doesn't make sense why turning off ipv6 works, the hosts file entry should override DNS, so it should only try those ipv4 addresses and not even try ipv6.
The workaround sounds like only option for now (for those having the issue), until they have someone fix it. Smells of a DNS issue - or a misconfiguration, I think they need to have someone come in to check all the servers and networking, make sure everything is configured and running as needed.
Taking care of systems/networks like this is what I used to do, frustrating to not be able to fix things from the user side. If they needed help, I'd love to help (I'm sure many of us would). But from what I can see no one from the project is actually watching the forums, so...

Do a Timothy McGee or Penolpe Garcia and hack their system. lol