If you study the Grafana dashboard for Rosetta you can see when large groups of work were released and when tasks were generated to be released.

https://grafana.kiska.pw/d/boinc/boinc?orgId=1&var-project=Rosetta@Home&from=now-7d&to=now

Bill F

---

In October 1969 I took an oath to support and defend the Constitution of the United States against all enemies, foreign and domestic;
There was no expiration date.

If you study the Grafana dashboard for Rosetta you can see when large groups of work were released and when tasks were generated to be released.

https://grafana.kiska.pw/d/boinc/boinc?orgId=1&var-project=Rosetta@Home&from=now-7d&to=now

Thanks Bill - I keep forgetting that page. I must bookmark it
But I'm thinking more of whether the project is converting the 1.8m queued tasks so they're ready to send - and it's still not.
Let alone fixing the out-of-date security certificates of servers that's catching everyone out - no dice there either.
Let alone all the other technical things that go way over my head and I can't recall to even mention.

I don't think I'm asking too much - except it appears I am...

---

If you study the Grafana dashboard for Rosetta you can see when large groups of work were released and when tasks were generated to be released.

https://grafana.kiska.pw/d/boinc/boinc?orgId=1&var-project=Rosetta@Home&from=now-7d&to=now

Thanks Bill - I keep forgetting that page. I must bookmark it
But I'm thinking more of whether the project is converting the 1.8m queued tasks so they're ready to send - and it's still not.
Let alone fixing the out-of-date security certificates of servers that's catching everyone out - no dice there either.
Let alone all the other technical things that go way over my head and I can't recall to even mention.

I don't think I'm asking too much - except it appears I am...

Noticed it yesterday and it's still the case - assimilation building up a backlog too.
I don't think much of that maintenance

---

128.95.160.156 boinc-files.bakerlab.org

Yep, that's work, thx!

By the way... how did you know that this server(128.95.160.156) also handles download requests by boinc-files.bakerlab.org hostname?
Was it a simple iterating through university IP addresses?..
Or did one of the staff share such information?

Although I have very rarely crunched for this project and visited this forum even less often over the past years, this is not the first time I have seen these strange "dirty hacks" just to get BOINC to work with this project...
It looks extremely stupid and depressing : /

i don't know, i just grab it there on this forum ^^

128.95.160.156 boinc-files.bakerlab.org

Yep, that's work, thx!

By the way... how did you know that this server(128.95.160.156) also handles download requests by boinc-files.bakerlab.org hostname?
Was it a simple iterating through university IP addresses?..
Or did one of the staff share such information?

Although I have very rarely crunched for this project and visited this forum even less often over the past years, this is not the first time I have seen these strange "dirty hacks" just to get BOINC to work with this project...
It looks extremely stupid and depressing : /

Someone discovered it here in late March

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).

---