It looks as if orbit-fitting tasks in the new data feed (04_03_2024 in the task name) also have the problem that the previous feed (03_29_2024) had. (And like the previous data-set, the task names don't have "orbit_fitting" in them this time, which might hint at what the previous problem was!)

I still have some retries for earlier dates and those are viable.

Cheers - Al.

Since you looked over the data set naming did you notice the data sets have a 4 day cycle (excluding weekends)?

Einstein longs are about 3 days. Switched to them and will check back Wednesday.

Off topic, is my Marmot avatar showing?

This project is using all eight available cores while another project is trying to run. Why is that?

I rejoined after long absence and uploaded the new link. Now the work unit keeps getting stuck and the only solution is to reboot which is not always convenient, currently stuck for 3rd time after c.30% progress. WCG has the same issue after changing servers, but usually one reboot is enough

Are you using an app_config.xml file to limit the number of cpu cores the app can use? If not the one Link has is very helpful, the problem seems to be that if MilkyWay is using all of your cpu cores to crunch with then when the pc wants to do something else, ie check you mail, open a webpage etc, it stops crunching and then doesn't resume crunching again.

Conan,

As suggested by MIchael Setzer II in the News forum, you could add the following to your /etc/hosts file so that your client(s) can still get at the server using the now-withdrawn name. You should be able to run down your work to a point where you can take action to restore the original site name!

128.113.126.54 milkyway-new.cs.rpi.edu

This was working for me until the various BOINC scheduler services were taken offline some time on th eevening of 28th November (confirmed by the server status page); uploads are still getting through but then sit at "Ready to report" and, of course, downloads aren't possible at present (no scheduler...)

Hope this helps in some way.

Cheers - Al

Marcin wrote:

another issue to report!
I am getting hostname resolution errors now:
[code]34852: 19-Nov-2023 11:13:37 (low) [Milkyway@home] Sending scheduler request: To report completed tasks.
34853: 19-Nov-2023 11:13:37 (low) [Milkyway@home] Reporting 1 completed tasks
34854: 19-Nov-2023 11:13:37 (low) [Milkyway@home] Not requesting tasks: don't need (job cache full)
34855: 19-Nov-2023 11:13:42 (low) [] Project communication failed: attempting access to reference site
34856: 19-Nov-2023 11:13:42 (low) [Milkyway@home] Scheduler request failed: Couldn't resolve host name

[quote]It seems that I can eliminate the issue locally in the client by shutting down the client, removing the <scheduler_url>url</scheduler_url> line from client_state.xml, and restarting the client. But that's just a workaround of course, the real fix needs to happen on the server.

I have 17 pc's running here at my home and get that at every Project over the course of a day as I manually update them, I REALLY dislike seeing a whole page of completed tasks sitting there waiting to be returned and also dislike seeing tasks that are stuck uploading so I will keep clicking until they get returned or uploaded as the case may be. Now if your 'fix' really does fix it then I wonder if it's the change-over to https from http that is causing the problems I'm seeing at all the other projects?

mikey - for information:

"PERF" as in Ithena Measurements Perf tasks? If so it's like any other Boinc project you choose what kind of tasks you want to run, Perf is for Windows only while Ooni tasks are Linux only and the Cnode tasks are for both I think. There is also a Project Ithena computation that has Hex tasks https://comp.ithena.net/usr/

Nope - we're talking Linux, and perf is one of a set of kernel-specific system tools; it offers various different ways of looking at system performance...

Cheers - Al.

P.S. the ... post you made and I assume you wanted to delete it, changing to two spaces makes it go away. Weird, but it works.