think the real reason is that if you want to run Separation only on the GPU, you have to turn off "Use CPU". Then, you of course can't run the N-Body.
You need to allow running the Separation GPU work units only, without the CPU Separation work units, while still allowing N-Body to run on the CPU.

(Don't someone tell me to use two BOINC instances. I have been doing that for ages. Not many people will.)

I'd love to make this change to the project. It's something that I've put on the list for the new project devs to look at down the line. It's frustrating that we force our users to have to run 2 configured instances of the client in order to effectively use their machines.

The latest Nbody Simulation tasks are taking a lot of resources, over two hours across 8 CPU’s 16 hours plus cpu time. They were previously taking 4-6 minutes when I did them before. Can see why people are reluctant to run them.

I am working on a response to that issue in this thread: [url] https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=4924#74181 [/url]. I also talk about it a little bit below.

In response to long running tasks.... FYI, over the years, it seams that when a new task group starts, i.e. the ones with the lowest numbers (like below 1000000) in the task name just before the last _ (underscore) will have long run times. The higher the number the shorter the run time. So as we crunch through the low numbers, the run times typically and historically become shorter until the next group hits, and the next group of 3 sequence starts. And but however, this often takes many weeks.

As a speculative guess, and I suppose it would have to be the milky-way staff that would have to reply, I would think the low numbers start off as a point - or pixel close to the core of the milky-way, and then as the number increment, the referenced position advance outward. The further from the center, there would be lesser effects on that position, meaning faster crunch time?

I would not hold my breath for any staff response, as I rarely see any staff from any site reply with additional information. In the mean time... we can speculate.

The way that the simulation and optimization works, there is no preference to place the dwarf galaxy at a specific point in the Milky Way. There are combinations of parameters (such as very dense dwarf galaxies) that cause the simulation to run for a long time. This is usually because the timestep resolution that you need to accurately simulate those systems is very small, so the simulation may choose to run 10,000 timesteps for very dense systems, but only 1,000 timesteps for a less dense system. Timesteps all take roughly the same amount of time to run, so in this example that would be a 10x increase in the time it would take to crunch that simulation.

Over time, these very dense systems should be ruled out (I say should... it appears they may not be ruled out in all cases) and you will only get simulations with the reasonable less dense dwarf galaxies, that don't take very long to run. So your average runtime goes down.

I contribute to various projects but sometimes focus on one at a time also. I assume that's what you're doing too. I'd just hope that people wouldn't stop contributing because project is experiencing some difficulties.

Yes I am doing the same as you in regards to currently focusing on a particular project. I agree I hope people don't stop contributing just because the project is experiencing some difficulties. I will do the best to empty my cache by the deadline

I've had a bunch of tasks, usually 8 CPU de_nbody tasks that should take about 9 minutes, but the longer they run, the longer they have left to run, and aren't using any CPU time, finally they never finish and throw a "computation error" message. On the other hand, I've had a bunch that don't pause when I pause BOINC. BOINC manager shows them paused, but TaskManager shows they're still running under VBox, even if I quit BOINC completely. A reboot finally kills it.
I've just suspended Milkyway because I have anooher task that's been running for hours, but not making progress. The longer I've let it run the more time remains. before it will finish. At that rate it never will.
DaveH52

I've had a bunch of tasks, usually 8 CPU de_nbody tasks that should take about 9 minutes, but the longer they run, the longer they have left to run, and aren't using any CPU time, finally they never finish and throw a "computation error" message. On the other hand, I've had a bunch that don't pause when I pause BOINC. BOINC manager shows them paused, but TaskManager shows they're still running under VBox, even if I quit BOINC completely. A reboot finally kills it.
I've just suspended Milkyway because I have anooher task that's been running for hours, but not making progress. The longer I've let it run the more time remains. before it will finish. At that rate it never will.
DaveH52

Your pc is hidden so I can't tell is your pc an 8 core pc and you are letting the nbody tasks use every cpu core you have? If so you should try an app_config file to reduce that to say 4 cpu's, the problem seems to be the task is waiting for the pc to do something but with all the cpu cores tied up by the task it either can't happen or it takes forever to happen.

Notice still displayed in Bionic Manager even though its outdated.

Notice still displayed in Bionic Manager even though its outdated.

Notice still displayed in Bionic Manager even though its outdated.

What notice is that?

Notice still displayed in Bionic Manager even though its outdated.

What notice - I can't see a notice in the post you have refered to.

I think they are talking about the Server Maintenance message from 9/23 that still pops up in BOINC Manager.

You are right, I sort of mistunderstood it.
Thanks.

I've turned off exporting of this notice, hopefully that fixes it. Sometimes that can get stuck or keep showing up if the threads are busy (I still don't know if that's intended behavior from BOINC or if it's a bug).

I am certainly relieved that the worrisome Notice won't be showing up on my computer any longer. However, I am concerned that the Project may be crashing. Task completions are down 40% and are falling.
You can't look at any of the various elements of the process and say that it is working well. Task creation, Task distribution, Task execution, Task completion. Task validation and Task error detection are seriously flawed.?
If we can't get back on course we are going to crash. What I need to know is, are we going to correct our course and get this turkey under control or load the life boats?

I think I'm cursed so that whenever I travel, the server begins to time out. I was on a plane most of yesterday so I wasn't looking at milkyway, and then I got an email this morning telling me it had downages in the middle of the night.

This morning the server seemed to be running just fine again, but I restarted some processes and flushed the DB just in case. It all seems fine on my end, and the numbers look like they're improving.

We're very close to breaking through that 1k nbody task waiting limit at which point a these validation waiting WUs should begin to clear out.

I think I'm cursed so that whenever I travel, the server begins to time out. I was on a plane most of yesterday so I wasn't looking at milkyway, and then I got an email this morning telling me it had downages in the middle of the night.

This morning the server seemed to be running just fine again, but I restarted some processes and flushed the DB just in case. It all seems fine on my end, and the numbers look like they're improving.

We're very close to breaking through that 1k nbody task waiting limit at which point a these validation waiting WUs should begin to clear out.

Can you run a script once per week to do what you just did? Would that help?

We're very close to breaking through that 1k nbody task waiting limit at which point a these validation waiting WUs should begin to clear out.

Thanks for keeping us up-to-date Tom, hope your trip went well. To help lower pending validations quicker would it be helpful to focus/process more N body tasks?

Hello,

Is what I am reading here why I am having such a large percentage of tasks failing because task was not started by deadline?

Hello,

Is what I am reading here why I am having such a large percentage of tasks failing because task was not started by deadline?

No it's not the reason why you are having such large percentage of tasks not started before deadline. Reason why you are having this happen is because your computer is not able to process the work before the deadline. This is not your fault you just have too many tasks in progress.
I would suggest setting "no new tasks" in your "project tab"

Is there a way I can set the project so I don't have this issue? The No New Task setting is only a temporary fix. This issue just cropped on recently also which makes me think there has been a change.

Is there a way I can set the project so I don't have this issue? The No New Task setting is only a temporary fix. This issue just cropped on recently also which makes me think there has been a change.

Reduce the amount of tasks in your queue.
Under "Options" --> "Computing preferences" --> "Store at least X days of work"
and "Store up to an additional X days of work".
Start with 0.1 and 0.1 respectively.
Then work your way up - till you get just few task in your queue.
That way you avoid running into deadlines.

Tasks are running much longer than previously.
Sometimes up to 24 hours and more - especially on "slow" PCs.

Hope this helps ...

Thank you very much! I will give it a try.