Welcome to MilkyWay@home

N-Body and the Bunker

Message boards : Number crunching : N-Body and the Bunker
Message board moderation

To post messages, you must log in.

AuthorMessage
POPSIE

Send message
Joined: 25 Jan 11
Posts: 12
Credit: 16,960,651
RAC: 0
Message 53143 - Posted: 13 Feb 2012, 20:30:29 UTC

Now I understand the world is not at all.
Bad habit he moved to 12 WU's are very rare, and holds the bunker to 12
Then he builds from the bunker to 1 every 2 minutes and invites a new WU, and processes them.
It then goes on for hours and days Keep it up.
Why did he then sometimes it takes 12 WU's because I'm not yet come back.
But why only 12 place settings and allow much more!

Because maybe someone has an idea of what debug parameters to get behind the riddle?
Or someone has a special tip for settings?
My local recruitment attempts in the files or remotely via an account I did not learn much here.

There you can find messages and settings from my OpenSuse 11.4 based system core 4
ID: 53143 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile kashi

Send message
Joined: 30 Dec 07
Posts: 311
Credit: 149,490,184
RAC: 0
Message 53155 - Posted: 14 Feb 2012, 6:01:37 UTC - in response to Message 53143.  
Last modified: 14 Feb 2012, 6:04:14 UTC

I'm not sure I understand your question. However if you are asking about the cache, then BOINC development 7.0.xx versions work differently to currently released BOINC versions for cache.

With BOINC 7.0.xx versions "Connect about every x.xx days" is now minimum cache and will be renamed to "Minimum work buffer" in the most recent BOINC 7.0.xx versions.

http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=2764&nowrap=true#53062

http://www.worldcommunitygrid.org/forums/wcg/viewthread_thread,32530
ID: 53155 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Len LE/GE

Send message
Joined: 8 Feb 08
Posts: 261
Credit: 104,050,322
RAC: 0
Message 53157 - Posted: 14 Feb 2012, 10:08:33 UTC

Ok, did check the german thread he was linking to.
Whatever translator was used, it's trashware :)

He is running nbody on a 64bit Linux (OpenSUSE) with BM 7.0.8, system is Athlon II X4 640.
His problem is, most of the time he only gets 1 or 2 WUs. Only once in a while he gets a load of 12 (and not more).

My 2 cents are on the different cache handling in BM 7 too :)

ID: 53157 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
FruehwF

Send message
Joined: 28 Feb 10
Posts: 120
Credit: 109,840,492
RAC: 0
Message 53194 - Posted: 15 Feb 2012, 13:45:39 UTC

The WU-Limit for CPU is 3/ Core so you get maximum 12 WU's.
This is a Limt from MW Server i dont think the BM 7 can overrule this.
In the Moment the N-Body WU's are damed short.
IF you only do N-Body you musst do every minute an update (you can do this with boinccmd.exe

[german]

Das WU Limt von MW@H ist 3 / Core, damit bekommst du nur maximal 12 WU's.
Ich denke BM 7 kann das auch nciht übersteueren. Und im Moment sind die N-Body WU's verdammt kurz bei der Laufzeit, wenn man nur N-Body rechnet, dann müsste man jede Minute einen manuellen Update machen (könnte man mit boinccmd.exe automatisieren)

ps: lass deine Sachen nicht durch einen Ãœbersetzer durch, die sind Schrott, schicks vorher lieber mir
[/german]
ID: 53194 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Link
Avatar

Send message
Joined: 19 Jul 10
Posts: 578
Credit: 18,845,239
RAC: 856
Message 53212 - Posted: 16 Feb 2012, 11:16:48 UTC - in response to Message 53194.  

The WU-Limit for CPU is 3/ Core so you get maximum 12 WU's.
This is a Limt from MW Server i dont think the BM 7 can overrule this.
In the Moment the N-Body WU's are damed short.
IF you only do N-Body you musst do every minute an update (you can do this with boinccmd.exe

Not necessary to do manual update via boinccmd.exe, he's settings are now according to the german thread <work_buf_min_days>0</work_buf_min_days>, <work_buf_additional_days>2</work_buf_additional_days>, he simply needs to switch the numbers to <work_buf_min_days>2</work_buf_min_days>, <work_buf_additional_days>0</work_buf_additional_days>, than BOINC 7 will try to have at least 2 days of work in cache and will ask for work as often as the server allows to, so every minute. With the current settings BOINC 7 tries to keep 0 days of work, i.e. nothing, and when it asks for work, it asks for 2 days of work. If it gets than at least 1 WU, it has more than nothing in cache, so it stops asking as it is enough according to the work_buf_min_days setting.


German:
Setze deine Einstellungen zu <work_buf_min_days>2</work_buf_min_days>, <work_buf_additional_days>0</work_buf_additional_days>.

Deine aktuellen Einstellungen bedeuten für BOINC 7, dass es arbeit für mindestens 0 Tage (also nichts) im Cache haben soll und wenn es denn mal nach Arbeit fragt, soll er gleich für 2 Tage anfordern. Sobald er aber auch nur eine WU bekommen hat, hört er auf weitere WUs anzufordern, denn er hat ja damit bereits mehr als für 0 Tage.

Wenn er immer Arbeit für ungefähr 2 Tage haben soll, sprich so, wie BOINC 6 das mit den Einstellungen gemacht hätte, musst du die Werte vertauschen. Du wirst damit zwar nicht das 3WU/CPU-Kern Limit umgehen können, aber BOINC sollte dann selbständig jede Minute nach Arbeit fragen, es sei denn die n-Body WU werden mal länger, so dass 12 von denen deinen 2 Tage Cache füllen werden.
ID: 53212 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
POPSIE

Send message
Joined: 25 Jan 11
Posts: 12
Credit: 16,960,651
RAC: 0
Message 53266 - Posted: 18 Feb 2012, 15:00:56 UTC
Last modified: 18 Feb 2012, 15:04:04 UTC

I checked with BOINC 6.10.60, 6.12.34, 6.13.1 and 7.0.8.
Played with parms of work_buf_min_days and work_buf_additinonal_days.
On all versions and different work_buf parameters he's starting first time with 8-12 WU's for a while, then he goes down to one WU and then every minute one new WU. I never get a filled bunker.
I also played with cpu using parameters, result of all, no bunker, only one WU per minute. Every WU needs 11 sec. CPU to finish.

And now my last settings on my openSUSE 12.1 Core 4 system with BOINC 7.0.8:
<venue name="school">
<run_on_batteries>1</run_on_batteries>
<run_if_user_active>1</run_if_user_active>
<run_gpu_if_user_active>1</run_gpu_if_user_active>
<idle_time_to_run>3</idle_time_to_run>
<suspend_if_no_recent_input>0</suspend_if_no_recent_input>
<suspend_cpu_usage>25</suspend_cpu_usage>
<leave_apps_in_memory>1</leave_apps_in_memory>
<cpu_scheduling_period_minutes>60</cpu_scheduling_period_minutes>
<max_cpus>4</max_cpus>
<max_ncpus_pct>100</max_ncpus_pct>
<cpu_usage_limit>100</cpu_usage_limit>
<disk_max_used_gb>100</disk_max_used_gb>
<disk_min_free_gb>0.001</disk_min_free_gb>
<disk_max_used_pct>50</disk_max_used_pct>
<disk_interval>20</disk_interval>
<vm_max_used_pct>75</vm_max_used_pct>
<ram_max_used_busy_pct>50</ram_max_used_busy_pct>
<ram_max_used_idle_pct>90</ram_max_used_idle_pct>
<work_buf_min_days>8</work_buf_min_days>
<work_buf_additional_days>2</work_buf_additional_days>
<confirm_before_connecting>0</confirm_before_connecting>
<hangup_if_dialed>0</hangup_if_dialed>
<max_bytes_sec_down>0</max_bytes_sec_down>
<max_bytes_sec_up>0</max_bytes_sec_up>
<daily_xfer_limit_mb>0</daily_xfer_limit_mb>
<daily_xfer_period_days>0</daily_xfer_period_days>
<dont_verify_images>0</dont_verify_images>
</venue>
ID: 53266 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Link
Avatar

Send message
Joined: 19 Jul 10
Posts: 578
Credit: 18,845,239
RAC: 856
Message 53272 - Posted: 18 Feb 2012, 18:40:54 UTC - in response to Message 53266.  

I checked with BOINC 6.10.60, 6.12.34, 6.13.1 and 7.0.8.
Played with parms of work_buf_min_days and work_buf_additinonal_days.

Where did you change them? Online Preferences or BOINC Manager?


On all versions and different work_buf parameters he's starting first time with 8-12 WU's for a while, then he goes down to one WU and then every minute one new WU. I never get a filled bunker.
I also played with cpu using parameters, result of all, no bunker, only one WU per minute. Every WU needs 11 sec. CPU to finish.

Well, with 11 seconds per WU it will be difficult to have it running at 100% all the time, basically one "no tasks available" answer from the server lets your machine idle, even if your cache was full after the previous sheduler request. So unless you add another project for CPU, you'll have to live with it.

If you add another project and would like to give all possible resources to Milkyway, you'd have to set cpu_scheduling_period_minutes to something very low, maybe even just 1 minute. And of course the resource share of that project would have to be very low... 0 could work good with v6.12.34.

And I'd suggest also:
<suspend_cpu_usage>0</suspend_cpu_usage>

Rest looks good.
ID: 53272 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
POPSIE

Send message
Joined: 25 Jan 11
Posts: 12
Credit: 16,960,651
RAC: 0
Message 53273 - Posted: 18 Feb 2012, 19:33:59 UTC

Where did you change them? Online Preferences or BOINC Manager?

Stop Client, change on local system(global_prefs.xml), Start Client

If you add another project and would like to give all possible resources to Milkyway, you'd have to set cpu_scheduling_period_minutes to something very low, maybe even just 1 minute. And of course the resource share of that project would have to be very low... 0 could work good with v6.12.34.

With other projects and parts of Milkyway the bunker-problem doesn't exist, I've tested. It only affects the N-Body.

On moment I'm on 7.0.8 for test, should I go back to 6.12.34?
And I'd suggest also:

<suspend_cpu_usage>0</suspend_cpu_usage>

I've set to on local system prefs-file, restart client, but no other results.
ID: 53273 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Link
Avatar

Send message
Joined: 19 Jul 10
Posts: 578
Credit: 18,845,239
RAC: 856
Message 53282 - Posted: 18 Feb 2012, 22:03:52 UTC - in response to Message 53273.  
Last modified: 18 Feb 2012, 22:13:55 UTC

Where did you change them? Online Preferences or BOINC Manager?

Stop Client, change on local system(global_prefs.xml), Start Client

Yeah, I suspected that from the way you posted your settings and that gets overwritten on the next sheduler request. Use BOINC Manager instead to create local preferences for this machine, no need to shut down BOINC for that. It would work if you edited global_prefs_override.xml, but why make it that complicated?

EDIT: maybe it does not get overwritten, when I look into my BOINC data folder... but it will as soon as you change something online, so better use the propper way for creating local preferences. Anyway, the settings are not the real reason for your problem.


If you add another project and would like to give all possible resources to Milkyway, you'd have to set cpu_scheduling_period_minutes to something very low, maybe even just 1 minute. And of course the resource share of that project would have to be very low... 0 could work good with v6.12.34.

With other projects and parts of Milkyway the bunker-problem doesn't exist, I've tested. It only affects the N-Body.

Yes, that's why the solution is to have more than just n-Body for the CPU. With the currently very short n-Body WUs in combination with the 3 WUs per core limit, without a backup project for the CPU, you just must run out of work.


On moment I'm on 7.0.8 for test, should I go back to 6.12.34?

Yes... unless you really need some function from that version, you should use the currently recommended version, or any other older one, that was a recommended version, when it was new. Always avoid using dev/beta versions. But IIRC it's not that easy to go back from 7.x.x to 6.x.x, either you will have to complete and report all your tasks before the downgrade, or you will have to google for the way how to do it, I can't find the instructions I saw once... somewhere.


And I'd suggest also:

<suspend_cpu_usage>0</suspend_cpu_usage>

I've set to on local system prefs-file, restart client, but no other results.

It just prevents the work to be suspended when the CPU load of non-BOINC applications goes above 25%, nothing related with your issues, just a general recommendation to minimize wasting resources and get more science done.
ID: 53282 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
FruehwF

Send message
Joined: 28 Feb 10
Posts: 120
Credit: 109,840,492
RAC: 0
Message 53339 - Posted: 20 Feb 2012, 16:00:19 UTC

I was able to rebuild Popsie'sproblem, and I think it's realy an issue!

He wants to do only N-body on his machine.
At the start of boinc-manager the machine gets 12 WUs. Every Minute it pulls new WU's, but obviosly there is a limit off maximum 4 WU's per pull But his machine does more then 4 WU's in a minute.
So the work-chache reduces more and more. At the end it pulls only one WU per pull.

The questions are: Why ist there a limit for CPU WU of 4 per request?
Why are the N-Body WU's so damned small?
And finaly: From sight of MW Project-Managers: Does it make sense to do only N-Body?

Deutsch

Ich konnte das Problem von Popsi nachstellen, und ich denke es ist wirklich eine Anforderung:

Er möchte nur N-Body auf seiner Maschine laufen lassen.
Zu Beginn erhält man 12 WU's. Jede Minute erfolgt dann ein automatischer Request für neue WU's. Offensichtlich gibt es aber ein Limt, dass mann nur 4 WU/Request bekommt. Sein Rechner schaft aber mehr als 4 WU's pro Minute, und so wird der Vorrat immer kleiner. Zum Schluss wird gar nur mehr eine WU pro/Request geliefert.
Die Fragen, die sich stellen sind:
Warum gibt es dieses 4 WU Limti pro Request?
Warum sind die N-Body WU's so verdammt klein?
Und schliesslich: Aus Sicht der Projekt-Verantwortlichen: Macht es überhaupt Sinn nur N-Body rechnen zu lassen?
ID: 53339 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
POPSIE

Send message
Joined: 25 Jan 11
Posts: 12
Credit: 16,960,651
RAC: 0
Message 53341 - Posted: 20 Feb 2012, 16:44:25 UTC

Thank you for your help.
I thought I was too stupid to handle it properly.
Hopefully waiting good news comes up for N-Body

[Deutsch]
Vielen Dank für deine Untertützung und Mühe.
Ich dachte schon ich sei zu blöde es richtig zu handhaben.
Dann warte ich mal, bis es neue, gute Nachrichten für N-Body gibt.
ID: 53341 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Link
Avatar

Send message
Joined: 19 Jul 10
Posts: 578
Credit: 18,845,239
RAC: 856
Message 53364 - Posted: 21 Feb 2012, 10:22:46 UTC - in response to Message 53339.  

Yeah... that sounds like an issue. Still, the only solution I see until the n-body WUs get bigger or the limits changed is running an other project with very low resource share on the CPU together with n-body and use very fast switching between applications (and keep applications in memory when idle). That's as close as you can get to run only n-body on CPU and not have any idle time.
ID: 53364 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Number crunching : N-Body and the Bunker

©2024 Astroinformatics Group