Message boards :
Number crunching :
Ever longer N-Bodies
Message board moderation
Author | Message |
---|---|
Send message Joined: 5 Aug 13 Posts: 5 Credit: 1,689,686 RAC: 0 |
There seems to be an issue (for me at least) with "..nbody_06_10_orphan_sim.." N-Body WUs. They start off with a fairly low estimated time left of maybe an hour or less, but then this keeps increasing instead of decreasing. For example, I have one now which was originally down for completion in 1h28m but is still only 21.7% done after 22h13m. Other N-Body WUs seem to be fine. |
Send message Joined: 5 Aug 13 Posts: 5 Credit: 1,689,686 RAC: 0 |
Ok, so it's not just me - these runs seem to be causing a lot of errors. http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=573844938 http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=573673662 http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=573514882 http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=573704691 |
Send message Joined: 4 Sep 12 Posts: 219 Credit: 456,474 RAC: 0 |
Yes, that looks like a workunit setup problem by the project: a lot get Exit status 196 (0xc4) EXIT_DISK_LIMIT_EXCEEDED |
Send message Joined: 31 Oct 10 Posts: 83 Credit: 38,632,375 RAC: 0 |
Didn't have a problem with these until a couple of days ago - now starting to get errors on both the long and short WUs, all with the same problem - 196 (0xc4) EXIT_DISK_LIMIT_EXCEEDED. All of the errors are on the "1.4" units |
Send message Joined: 22 Jun 11 Posts: 32 Credit: 41,852,496 RAC: 0 |
Can an admin please investigate this issue? I too am getting the "EXIT_DISK_LIMIT_EXCEEDED" errors. Outcome Computation error Client state Compute error Exit status 196 (0xc4) EXIT_DISK_LIMIT_EXCEEDED <core_client_version>7.4.2</core_client_version> <![CDATA[ <message> Maximum disk usage exceeded </message> <stderr_txt> <search_application> milkyway_nbody 1.40 Windows x86_64 double OpenMP, Crlibm </search_application> Using OpenMP 8 max threads on a system with 8 processors de_nbody_06_10_orphan_sim_1_1398336302_1400388_3 http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=771700839 http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=576425580 de_nbody_06_10_orphan_sim_1_1398336302_1406796_2 http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=771728077 http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=576815078 |
Send message Joined: 18 Jul 09 Posts: 300 Credit: 303,593,762 RAC: 1,232 |
I am seeing these errors also. |
Send message Joined: 1 Jan 14 Posts: 24 Credit: 4,277,349 RAC: 0 |
I have one that is at 42% done after 26+ hours, lots of errors |
Send message Joined: 1 Jan 14 Posts: 24 Credit: 4,277,349 RAC: 0 |
I have one that is at 42% done after 26+ hours, lots of errors This N-Body ended up in error after over 50 hrs of computer time. |
Send message Joined: 31 Oct 10 Posts: 83 Credit: 38,632,375 RAC: 0 |
Sorry to say, but I gave up on the Ns .. after several WUs with 20-40 hours running time on 4 processors only to end up in error just wasn't an effective use of the resources |
Send message Joined: 8 May 09 Posts: 3339 Credit: 524,010,781 RAC: 0 |
Sorry to say, but I gave up on the Ns .. after several WUs with 20-40 hours running time on 4 processors only to end up in error just wasn't an effective use of the resources First don't count the 'inconclusive units' as bad just yet, they could end up being just fine. 2nd are you using all 4 cpu cores AND the gpu all at the same time? If so try using only 3 cpu cores, leaving the 4th one free to feed the gpu. Your gpu units should finish faster thus giving you even more credits then crunching on the cpu core ever could. Changing it is easy if you use the Boinc Manager, down by the clock, click once on the double up arrows, then double the Boinc icon click it to open it, then click Tools, computing preferences and you should see a several tabs each with some tweaking options. You want the first tab, processor usage, and the 2nd line up from the bottom, where it says "on multiprocessor systems, use at most [100] % of the processors (ero means ignore this setting). Put 99 in the box and then click the ok box at the bottom of the page and you will be crunching with one less cpu core on your machine. Only make this ONE change, as after you crunch a couple of gpu units you will want to go to the website and check your before the change and after the change times to ensure it did in fact help shorten your crunching times. You can look at all the other settings, but just click cancel when you are doing looking and they won't be saved. You can even go from tab to tab to see the different options, again NOT clicking the ok box just yet. If you have questions about how to use some of the other settings please ask, some can help your pc run faster, but some can make things worse. The defaults, which most people use just fine, are a generic setup that works for most people, but aren't what the fastest crunchers use. |
Send message Joined: 31 Oct 10 Posts: 83 Credit: 38,632,375 RAC: 0 |
"First don't count the 'inconclusive units' as bad just yet, they could end up being just fine. 2nd are you using all 4 cpu cores AND the gpu all at the same time? If so try using only 3 cpu cores, leaving the 4th one free to feed the gpu. Inconclusive units I can deal with. In fact, very VERY few of those ever end up in error. Its when 4 cores work for days and the result ends in ERROR, then it gets frustrating. My GPU is being "fed" by .247 worth of CPU. |
Send message Joined: 8 May 09 Posts: 3339 Credit: 524,010,781 RAC: 0 |
"First don't count the 'inconclusive units' as bad just yet, they could end up being just fine. 2nd are you using all 4 cpu cores AND the gpu all at the same time? If so try using only 3 cpu cores, leaving the 4th one free to feed the gpu. That 0.247 is a fake number, it is NOT real!! This is probably not a 'new' problem in Boinc, most likely we users are just realizing that it is fake though. I do know know what formula they are using, but the number has little to do with real life. |
©2024 Astroinformatics Group