Message boards :
Number crunching :
N-Body and the Bunker
Message board moderation
Author | Message |
---|---|
Send message Joined: 25 Jan 11 Posts: 12 Credit: 16,960,651 RAC: 0 |
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 |
Send message Joined: 30 Dec 07 Posts: 311 Credit: 149,490,184 RAC: 0 |
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 |
Send message Joined: 8 Feb 08 Posts: 261 Credit: 104,050,322 RAC: 0 |
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 :) |
Send message Joined: 28 Feb 10 Posts: 120 Credit: 109,840,492 RAC: 0 |
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] |
Send message Joined: 19 Jul 10 Posts: 603 Credit: 19,114,122 RAC: 5,338 |
The WU-Limit for CPU is 3/ Core so you get maximum 12 WU's. 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. |
Send message Joined: 25 Jan 11 Posts: 12 Credit: 16,960,651 RAC: 0 |
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"> |
Send message Joined: 19 Jul 10 Posts: 603 Credit: 19,114,122 RAC: 5,338 |
I checked with BOINC 6.10.60, 6.12.34, 6.13.1 and 7.0.8. 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. 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. |
Send message Joined: 25 Jan 11 Posts: 12 Credit: 16,960,651 RAC: 0 |
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: I've set to on local system prefs-file, restart client, but no other results. |
Send message Joined: 19 Jul 10 Posts: 603 Credit: 19,114,122 RAC: 5,338 |
Where did you change them? Online Preferences or BOINC Manager? 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. 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: 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. |
Send message Joined: 28 Feb 10 Posts: 120 Credit: 109,840,492 RAC: 0 |
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? |
Send message Joined: 25 Jan 11 Posts: 12 Credit: 16,960,651 RAC: 0 |
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. |
Send message Joined: 19 Jul 10 Posts: 603 Credit: 19,114,122 RAC: 5,338 |
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. |
©2024 Astroinformatics Group