Expect N-Body 1.38 on Monday or Tuesday.

When the time comes, post comments here.

Jake

Hello, I had to quit this job de_separation_DR_8_rev_3_1_2_1378743565_3063657
and another one that seemed to be running forever (over 60 hours). I also see that lately 4 out of 5 tasks have errors in them.

---

Try posting this in one of the separation threads. This thread is specifically for issues with the n-body application. Someone on the other thread should have an answer for you.

Jake

and all I get is 1.28 which I have to abort because all they do is crash.

The ones you have been aborting are "Milkyway@Home Separation (Modified Fit) v1.28"

Not N-Body. Not this thread.

yeah..sorry...getting my tasks confused.

With MT or without MT...

Is there any project advantage to running the MT app over the non-MT app? I have been running both for a while now and for the most part they return about the same cr/effort across my computers. If anything, the non-MT actually has a better cr/effort ratio.

MT on the other hand plays "less nice" with other WU's as they demand all threads and kick the other WUs into the "waiting to run" state. Thankfully the MT WUs are quite fast and only a minor inconvenience. [Try Yafu and their 12+hr mt WUs messing up Boinc scheduling big time.]

So I am wondering, if there is no project advantage to MT why not just go the non-MT route? Or create a preference allowing one or the other or both?

We noticed this was a problem. I am of the opinion that there is no inherent advantage to running MT tasks and plan to release only non-MT versions for the next n-body release.

These N-Body 1.38 simulation WU's use 8 cores of my i7 with HT on. If I set to use only 90% of the cores to use, si that I can use one for GPU feeding, they don't run anymore, waiting to run.
Why is that? In the past these N-Body's run with all the available cores.
Thanks.

---

Greetings from,
TJ

There is a long overhead time in these runs due to the way we generate our particle distributions. This process is not multithreaded and takes awhile, but it should still say that it is running. I will look into it.

These N-Body 1.38 simulation WU's use 8 cores of my i7 with HT on. If I set to use only 90% of the cores to use, si that I can use one for GPU feeding, they don't run anymore, waiting to run.
Why is that? In the past these N-Body's run with all the available cores.
Thanks.

Because when you downloaded them they were set to use 8 cores, now that only 7 are available they are just waiting for the other core to become available. The only way to get rid of them is to either abort them or let them use that last core, or you can just wait them out and they will time out on their own and be recycled to someone else. Before you download any more set the pc to only use 7 of the cpu cores and the next batch will only want to use 7 cores, and you will be okay again.

We noticed this was a problem. I am of the opinion that there is no inherent advantage to running MT tasks and plan to release only non-MT versions for the next n-body release.

As alluded to in the previous posts, I have found another problem using MT apps. As TJ said, they want to use all cores. In my case, I am still using all cores, however, I am running another WU that is running in high priority (RNA World). In this situation the MT WU is not run and sits idle. Idle WUs, none the less, are figured into the work buffer computation making Boinc think that I have lots of WUs waiting to run. Consequently, the other threads start to run dry.

Because of this problem, I am now considering all MT apps (for any project) to be off-limits. Is it possible to separate the MT from non-MT n-Body WUs and add as a project preference?

I also wonder if it is possible to create a preference setting to limit the number of cpus used by MT apps. ...I should make a request on the Boinc forms...

As alluded to in the previous posts, I have found another problem using MT apps. As TJ said, they want to use all cores. In my case, I am still using all cores, however, I am running another WU that is running in high priority (RNA World). In this situation the MT WU is not run and sits idle. Idle WUs, none the less, are figured into the work buffer computation making Boinc think that I have lots of WUs waiting to run. Consequently, the other threads start to run dry.

Because of this problem, I am now considering all MT apps (for any project) to be off-limits. Is it possible to separate the MT from non-MT n-Body WUs and add as a project preference?

I also wonder if it is possible to create a preference setting to limit the number of cpus used by MT apps. ...I should make a request on the Boinc forms...

I believe this particular issue is with the BOINC scheduler, and will be corrected with the next public release of BOINC.

I had the same problem (idle CPUs due to high-priority RNA World task that was running combined with several downloaded MT tasks that could not get started). So I reported it, and they changed it so that BOINC will additionally schedule an MT task, even if it temporarily over-commits the system, thus no cores are left idle. You can get the latest Beta to see - BOINC v7.2.39 - http://boinc.berkeley.edu/download_all.php

Also, regarding limiting the number of CPUs for an MT task... You can actually specify "how many CPUs to consider as scheduled" and also "what command line argument to use to dictate how many threads to create". I think you'll also need the latest Beta to do it, but the options are available (even though they say 7.3) - http://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration ... For me, I use the following to indicate that I want to only consider 6 CPUs scheduled for a MW MT task (that way my GPU tasks and high-priority RNA World task can remain scheduled), but I don't change the command line, so I knowingly overcommit the system, all using the following:

<!-- Milkyway@Home -->
<app_config>
   <!-- MilkyWay@Home N-Body Simulation -->
   <!-- Set it up so BOINC only "schedules" 6 CPUs for the task -->
   <app_version>
      <app_name>milkyway_nbody</app_name>
      <plan_class>mt</plan_class>
      <avg_ncpus>6</avg_ncpus>
      <!-- <ngpus>x</ngpus>                 -->
      <!-- <cmdline>--nthreads 8</cmdline>  -->
   </app_version>
</app_config>

Cool!

Jacob, Thanks for working with the BOINC team to get the additional parameters included in the app_config file. And thanks for posting the new parameters in the thread.

I have it working now on one machine running Windows 7 and on one machine running Ubuntu.

No problem. The BOINC developers are nice guys, and they'll fix legitimate problems that get reported, especially those involving idle resources.