The good news is that you should be able to fix all of these with app_config from now on.

I do think a mistake was made with the 1.94 binary so it was not made as expected. The last run that was using v1.94 just finished, so unless you get one of the remaining tasks that still needs validation you will not see any more of those.

@gimmyk: can you please check why the server sends me sometimes a single thread task when I have selected 7 threads per task in the preferences? I think this should not happen and AFAICT it didn't happen before v1.94 was released. The main issue is they just sit there and wait for a single thread to become available which never happens so I have to abort them. This time the ST application is not just the MT application running with "--nthreads 1", so I can't override it via app_config.xml.

I would like more information about the current calculations.

N-body

The N-body project on Milkyway@home simulates dwarf galaxies colliding with (or being disrupted by) the Milky Way. This disruptions often result in tidal streams, like Sagittarius. The goal of the N-body project is to match simulated dwarf galaxies to real dwarf galaxy data, and thereby constrain the properties of the Milky Way galaxy's gravitational potential (as well as the properties of the dwarf galaxies).

So 08 Feb 2026 10:32:27 CET | Milkyway@home | Your app_config.xml file refers to an unknown application 'milkyway_nbody_orbit_fitting'. Known applications: 'milkyway_nbody'

What does "since Separation" mean?

and why does that mean no Apple Silicon tasks?

[EDIT2]

Now that I look more closely at the task output, I can see the input files were minimal and didn't require any processing. That is why the task only took 1 second to run.

Just add the following line to cc_config

<dont_use_docker>1</dont_use_docker>

Trying to then gather up a bunch of those to compute on a unified cluster of machines just doesn't seem very efficient?

Each box running with a central console for management should be able to do more work, with no exotic interconnections needed, just basic ethernet.

I tried setting it to "no restrictions" and it still selects 16.

I also tried forcing it to 20, but it still selects 16.

<core_client_version>8.2.8</core_client_version>
<![CDATA[
<stderr_txt>
<search_application> milkyway_nbody 1.94 Windows x86_64 double  OpenMP, Crlibm </search_application>
Using OpenMP 10 max threads on a system with 20 processors
Running MilkyWay@home Nbody v1.94
Optimal Softening Length = 0.002068807820259 kpc, Upper bound = 0.017975612260566 kpc, Lower bound = 0.000238098471147 kpc
Dwarf Initial Position: [-18.519759334690484,41.773119675543214,2.521461353061421]
Dwarf Initial Velocity: [28.335193244637974,167.381900791132637,-93.432151455203140]
Initial LMC position: [79.091156289642782,454.189801093785604,-196.850190073377576]
Initial LMC velocity: [-24.277471862838940,-168.921658317774501,38.174726064010969]
Initial body data written to 'initial.out'
<search_likelihood>-102.112417526875760</search_likelihood>
<search_likelihood_EMD>-16.136140380795954</search_likelihood_EMD>
<search_likelihood_Mass>-2.146054680655134</search_likelihood_Mass>
<search_likelihood_Beta>-21.231419499514832</search_likelihood_Beta>
<search_likelihood_BetaAvg>-22.865070427951220</search_likelihood_BetaAvg>
<search_likelihood_VelAvg>-22.501601939967848</search_likelihood_VelAvg>
<search_likelihood_Dist>-13.939768346258273</search_likelihood_Dist>
<search_likelihood_Momentum>-3.292362251732496</search_likelihood_Momentum>
strftime() failed called boinc_finish(0)

</stderr_txt>
]]>

Or am I missing something and is it possible to make, for example, 2 tasks together and 10 cores and threads each so that the tasks are MT and not ST?

They really do seem to be getting ever more frequent.