N-Body 1.38
log in

Advanced search

Message boards : News : N-Body 1.38

Author Message
Jake Bauer
Project developer
Project tester
Project scientist
Send message
Joined: 20 Aug 12
Posts: 66
Credit: 406,916
RAC: 0

Message 59942 - Posted: 20 Sep 2013, 19:52:44 UTC

Expect N-Body 1.38 on Monday or Tuesday.

When the time comes, post comments here.

Jake

Ron
Send message
Joined: 22 Sep 11
Posts: 1
Credit: 2,151,524
RAC: 673

Message 59958 - Posted: 23 Sep 2013, 8:03:15 UTC

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

Jake Bauer
Project developer
Project tester
Project scientist
Send message
Joined: 20 Aug 12
Posts: 66
Credit: 406,916
RAC: 0

Message 59968 - Posted: 24 Sep 2013, 0:12:20 UTC - in response to Message 59958.

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

Richard Haselgrove
Send message
Joined: 4 Sep 12
Posts: 218
Credit: 448,778
RAC: 0

Message 60106 - Posted: 4 Oct 2013, 18:49:13 UTC - in response to Message 60105.

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.

greg_be
Send message
Joined: 18 Aug 09
Posts: 83
Credit: 3,771,886
RAC: 4,523

Message 60107 - Posted: 4 Oct 2013, 22:26:38 UTC

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

Profile Werinbert
Send message
Joined: 30 Dec 12
Posts: 5
Credit: 1,008,772
RAC: 0

Message 60355 - Posted: 11 Nov 2013, 1:12:50 UTC

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?

Jake Bauer
Project developer
Project tester
Project scientist
Send message
Joined: 20 Aug 12
Posts: 66
Credit: 406,916
RAC: 0

Message 60357 - Posted: 11 Nov 2013, 5:40:07 UTC - in response to Message 60355.

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.

TJ
Send message
Joined: 12 Aug 09
Posts: 262
Credit: 87,503,055
RAC: 27,577

Message 60536 - Posted: 7 Dec 2013, 21:28:47 UTC

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

Jake Bauer
Project developer
Project tester
Project scientist
Send message
Joined: 20 Aug 12
Posts: 66
Credit: 406,916
RAC: 0

Message 60537 - Posted: 8 Dec 2013, 2:47:53 UTC - in response to Message 60536.

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.

mikey
Avatar
Send message
Joined: 8 May 09
Posts: 2033
Credit: 180,929,622
RAC: 307,694

Message 60538 - Posted: 8 Dec 2013, 11:55:07 UTC - in response to Message 60536.
Last modified: 8 Dec 2013, 11:56:17 UTC

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.

Profile Werinbert
Send message
Joined: 30 Dec 12
Posts: 5
Credit: 1,008,772
RAC: 0

Message 60729 - Posted: 13 Jan 2014, 2:01:10 UTC - in response to Message 60357.
Last modified: 13 Jan 2014, 2:02:25 UTC

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

Jacob Klein
Send message
Joined: 22 Jun 11
Posts: 32
Credit: 2,450,861
RAC: 7,170

Message 60956 - Posted: 4 Feb 2014, 13:19:40 UTC - in response to Message 60729.
Last modified: 4 Feb 2014, 13:36:24 UTC

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>

captainjack
Send message
Joined: 22 Jun 13
Posts: 40
Credit: 35,269,088
RAC: 0

Message 60963 - Posted: 4 Feb 2014, 20:21:14 UTC

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.

Jacob Klein
Send message
Joined: 22 Jun 11
Posts: 32
Credit: 2,450,861
RAC: 7,170

Message 60964 - Posted: 4 Feb 2014, 20:24:59 UTC - in response to Message 60963.

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


Post to thread

Message boards : News : N-Body 1.38


Main page · Your account · Message boards


Copyright © 2017 AstroInformatics Group