Message boards :
Number crunching :
post milkyway_windows_intelx86 problems here
Message board moderation
Previous · 1 · 2 · 3 · 4 · Next
Author | Message |
---|---|
Send message Joined: 13 Jan 08 Posts: 19 Credit: 820,482 RAC: 0 |
I was beginning to think it was just 6,4,1 and was about to revert to 6.2.19 but now that the purging is longer its on both versions. Yesterday and over night. Errors under 6.4.1 56895678 57113572 1 Dec 2008 14:10:57 UTC 1 Dec 2008 17:08:26 UTC Over Client error Compute error 2,007.23 8.20 -- 56547667 56776775 30 Nov 2008 9:36:45 UTC 30 Nov 2008 15:41:06 UTC Over Client error Compute error 817.96 3.34 --- 56917783 57132137 1 Dec 2008 21:24:41 UTC 2 Dec 2008 9:47:54 UTC Over Client error Compute error 1,089.28 4.45 --- 56917773 57132127 1 Dec 2008 21:24:41 UTC 2 Dec 2008 9:47:54 UTC Over Client error Compute error 1,013.43 4.14 --- Errors under 6.2.19 56917779 57132133 1 Dec 2008 21:24:28 UTC 2 Dec 2008 9:47:15 UTC Over Client error Compute error 3,560.44 15.25 --- 56917733 57132087 1 Dec 2008 21:24:28 UTC 2 Dec 2008 9:47:15 UTC Over Client error Compute error 3,544.23 15.18 --- 56917680 57132035 1 Dec 2008 21:24:28 UTC 2 Dec 2008 9:47:15 UTC Over Client error Compute error 3,584.02 15.35 --- 56917676 57132031 1 Dec 2008 21:24:28 UTC 2 Dec 2008 9:47:15 UTC Over Client error Compute error 3,557.36 15.23 --- 56903899 57120445 1 Dec 2008 16:59:12 UTC 2 Dec 2008 9:47:15 UTC Over Client error Compute error 3,558.42 15.24 --- 56897339 57115002 1 Dec 2008 14:48:05 UTC 1 Dec 2008 23:06:33 UTC Over Client error Compute error 3,558.73 15.24 --- I have just downloaded 06 and am presently running okay. michel |
Send message Joined: 20 Jun 08 Posts: 3 Credit: 649,825 RAC: 0 |
"This is a problem with the boinc manager actually. The time to completion should should sort itself out after a wu or two." I don't think that's true... I didn't keep an eye on Boinc the whole day, but this morning my work box was running these kind of WUs (with extremely large estimated run times) and in the afternoon it still was. No sorting itself out apparent. My work box is a dual core x86 windows machine. Thing is, at home, my dual x64/Linux box now does the same thing. So it +does+ seem related to the WUs after all...? I tend to think this all started with the *_stripe* WUs. |
Send message Joined: 20 Sep 08 Posts: 1391 Credit: 203,563,566 RAC: 0 |
The unit finished quite OK under V0.6 and claimed credit but I noticed this. Is it anything to worry about? <core_client_version>6.2.19</core_client_version> |
Send message Joined: 21 Nov 08 Posts: 90 Credit: 2,601 RAC: 0 |
The unit finished quite OK under V0.6 and claimed credit but I noticed this. Is it anything to worry about? This is just Stuff from BOINC 6 that projects havent implemented yet. The no heartbeat from core client for 31 sec - exiting line happens in many BOINC runs when youre running an intensive app like AV etc. |
Send message Joined: 20 Feb 08 Posts: 8 Credit: 9,928,369 RAC: 0 |
Getting the following error on the .6 app for windows 32 bit. Unrecognized XML in parse_init_data_file: computation_deadline Skipping: 1228416560.136000 Skipping: /computation_deadline Unrecognized XML in GLOBAL_PREFS::parse_override: mod_time Skipping: /mod_time Unrecognized XML in GLOBAL_PREFS::parse_override: max_ncpus_pct Skipping: 100.000000 Skipping: /max_ncpus_pct Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error Can't acquire lockfile - exiting FILE_LOCK::unlock(): close failed.: No error |
Send message Joined: 24 Jan 08 Posts: 6 Credit: 7,367,832 RAC: 0 |
Hello all, I've been getting the new Optimized 0.06 version and I've noticed that when the WU is downloaded it reports as 443 hour to complete and runs in high priority until it finishes. It generally finishes in 35 minutes to 57 minutes of CPU time but there are a couple of times where the WU will show as running but both the time to complete and the CPU Time will stop for about 1 to 2 minute at about 95% to 98%, when the WU continues it will rollback to 92% to 94% and when it get to 95% to 98% it will get stuck again and rollback again. I've noticed this on 2 of the 3 Optimized 0.06 version WU that have completed. I've haven't seen all of the WUs run but I'm working on my 4th and have seen these 1 to 2 minute pauses occur at different times but the rollback doesn't occur until it reaches the 95% to 98% mark. Could you give me some idea when BOINC will sort out the time to complete time? Usually it is sorted out after the second WU but for this version it has happened yet. Should I detach and the reattach after this WU finishes or just wait? Thank you, Warren Rogers |
Send message Joined: 17 Nov 07 Posts: 77 Credit: 117,183 RAC: 0 |
Should I detach and the reattach after this WU finishes or just wait? Hmmm. For 0.6 the highest estimated I've seen is 23:xx, with actual completion of 3:xx on a 1.4 GHz laptop. Detach might help? |
Send message Joined: 20 Jun 08 Posts: 3 Credit: 649,825 RAC: 0 |
...two days later, no change. Still getting *_stripe* WUs with extremely large estimated run times (>>100hrs). But these WUs get fully processed within an hour or so. Since these run times are so exceedingly large, Boinc is working in high priority mode all the time. I suppose that can't be good :-S Problem is, once one of these high-priority packets is reported, another one is downloaded, causing more high-prio processing. I don't know what the consequences are for my other Boinc projects, but it seems Boinc is running Milkyway all the time. That may be nice for this project, but it's not so kind towards the others I'm processing. Are there more Milkyway users seeing this problem? |
Send message Joined: 15 Aug 08 Posts: 163 Credit: 3,876,869 RAC: 0 |
Now, in the applications section from the home page, says that the current app for windows is the 0.07 but attaching a new computer the project downloads 0.06. Logan. BOINC FAQ Service (Ahora, también disponible en Español/Now available in Spanish) |
Send message Joined: 20 Sep 08 Posts: 1391 Credit: 203,563,566 RAC: 0 |
B^S] Astral Walker kindly suggested an code optimization which seems to be getting about a 10% speedup. I've updated the application again to v0.7 (at least the linux and osx binaries). Windows should be on its way when Dave gets it on the server. I've updated the code release directory as well. The Windoze version hasn't been added to the servers yet. Don't drink water, that's the stuff that rusts pipes |
Send message Joined: 28 Aug 07 Posts: 146 Credit: 10,540,236 RAC: 9,545 |
The Windoze version hasn't been added to the servers yet. Oh? Well as far as I see it is already... http://milkyway.cs.rpi.edu/milkyway/apps.php And my crunchers at home got work as well for this app. ...two days later, no change. Still getting *_stripe* WUs with extremely large estimated run times (>>100hrs). But these WUs get fully processed within an hour or so. Well, if it's still too high you could try to manually edit the client_state.xml-file. Open it with Notepad or something similar, search for the Milkyway part and then for the duration_correction_factor. If this value is very high, set it to 1, that should fix the high estimation time. Don't forget to restart BOINC after the editing. Member of BOINC@Heidelberg and ATA! My BOINCstats |
Send message Joined: 4 Oct 08 Posts: 1734 Credit: 64,228,409 RAC: 0 |
Whether the Windose version (0.6 or 0.7) has been added or not will be corrected in time. I was crunching on V0.4 recently, downloading the WUs marked Milkyway@Home Optimised 0.06 nm_stripes_xxx_xxx, when the client V0.6 was released. The system automatically upgraded my client and swapped crunching to the 0.06 WU. I expect the same to happen, in time, with the 0.7 client. |
Send message Joined: 6 Sep 07 Posts: 66 Credit: 636,861 RAC: 0 |
Now, in the applications section from the home page, says that the current app for windows is the 0.07 but attaching a new computer the project downloads 0.06. That's because there are probably WUs in the queues which were created when 0.6 was the latest version. As these drain out, those WUs created for 0.7 should kick in. HTH |
Send message Joined: 19 Nov 07 Posts: 29 Credit: 3,353,124 RAC: 0 |
That's because there are probably WUs in the queues which were created when 0.6 was the latest version. As these drain out, those WUs created for 0.7 should kick in. That's strange, because WUs don't store the app version. Only the appid, and the server will use whatever is the latest version for that app. Please use "Reply" or "Quote" buttons on posts, instead of "reply to this thread". Keep the posts linked together ("X is a reply to Y"). |
Send message Joined: 5 Dec 07 Posts: 6 Credit: 1,033,816 RAC: 0 |
i'm kinda lost when it comes to computer stuff so i don't know what happened here. i had to turn my computer off for a few minutes. when i restarted mw it immediately cancelled all the wu's i had in cache. of course no wu's are d/ling now. here is the message i got when i restarted wu: 12/4/2008 3:26:34 PM||Starting BOINC client version 5.10.45 for windows_intelx86 12/4/2008 3:26:34 PM||log flags: task, file_xfer, sched_ops 12/4/2008 3:26:34 PM||Libraries: libcurl/7.18.0 OpenSSL/0.9.8e zlib/1.2.3 12/4/2008 3:26:34 PM||Data directory: C:\Program Files\BOINC 12/4/2008 3:26:34 PM|SETI@home|Found app_info.xml; using anonymous platform 12/4/2008 3:26:34 PM||Processor: 1 GenuineIntel Intel(R) Pentium(R) 4 CPU 2.66GHz [x86 Family 15 Model 2 Stepping 9] 12/4/2008 3:26:34 PM||Processor features: fpu tsc sse sse2 mmx 12/4/2008 3:26:34 PM||OS: Microsoft Windows XP: Professional Edition, Service Pack 3, (05.01.2600.00) 12/4/2008 3:26:34 PM||Memory: 503.48 MB physical, 1.20 GB virtual 12/4/2008 3:26:34 PM||Disk: 37.27 GB total, 5.59 GB free 12/4/2008 3:26:34 PM||Local time is UTC -5 hours 12/4/2008 3:26:34 PM|Milkyway@home|URL: http://milkyway.cs.rpi.edu/milkyway/; Computer ID: 3221; location: (none); project prefs: default 12/4/2008 3:26:34 PM|SETI@home|URL: http://setiathome.berkeley.edu/; Computer ID: 3451353; location: home; project prefs: default 12/4/2008 3:26:34 PM||General prefs: from Milkyway@home (last modified 01-Dec-2008 15:13:07) 12/4/2008 3:26:34 PM||Host location: none 12/4/2008 3:26:34 PM||General prefs: using your defaults 12/4/2008 3:26:34 PM||Preferences limit memory usage when active to 251.74MB 12/4/2008 3:26:34 PM||Preferences limit memory usage when idle to 453.14MB 12/4/2008 3:26:34 PM||Preferences limit disk usage to 5.50GB 12/4/2008 3:26:34 PM|Milkyway@home|Restarting task nm_stripe79_r2_27555_1228382102_0 using milkyway version 6 12/4/2008 3:26:34 PM|Milkyway@home|Sending scheduler request: To fetch work. Requesting 222331 seconds of work, reporting 0 completed tasks 12/4/2008 3:26:39 PM|Milkyway@home|Scheduler request succeeded: got 0 new tasks 12/4/2008 3:26:45 PM|Milkyway@home|Computation for task nm_stripe79_r2_27555_1228382102_0 finished 12/4/2008 3:27:10 PM|Milkyway@home|Sending scheduler request: Requested by user. Requesting 263520 seconds of work, reporting 7 completed tasks 12/4/2008 3:27:15 PM|Milkyway@home|Scheduler request succeeded: got 0 new tasks and here is a link to the computer..it says it detached from project. and that is what has me puzzled...i didn't detach from mw.... link: http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=3221&offset=0 any clues???? |
Send message Joined: 20 Sep 08 Posts: 1391 Credit: 203,563,566 RAC: 0 |
Windoze V0.7 auto-downloaded on my pc at 16.00 UK time Don't drink water, that's the stuff that rusts pipes |
Send message Joined: 25 Nov 08 Posts: 1 Credit: 233,264 RAC: 0 |
Getting a lot of "Task nm_stripe86_r5_1879_1228457240_0 exited with zero status but no 'finished' file". The task is partly completed, usually over 50% then just stops and I get that message in the messages tab. It tries restarting the task "using milkyway version 7" but it never finishes the task. I've tried updating the project, resetting the project, and even detaching from the project and then re-attaching. Anybody know a way to fix this problem? I'm wasting a lot of time on tasks that will never finish... Any help would be great, thanks. |
Send message Joined: 20 Jun 08 Posts: 3 Credit: 649,825 RAC: 0 |
Quote- ==== Well, if it's still too high you could try to manually edit the client_state.xml-file. Open it with Notepad or something similar, search for the Milkyway part and then for the duration_correction_factor. If this value is very high, set it to 1, that should fix the high estimation time. ==== Yes, that seems to do the trick, thanks! Changed it from 23.6 to 0.6, which is still too high, apparently, but at least this is more reasonable. What I wonder, though, is: how did get to be so absurdly high? And on my work box and home box both, even though they're rather different setups? (dual x86/Win vs. dual x64/Linux) |
Send message Joined: 19 Nov 07 Posts: 29 Credit: 3,353,124 RAC: 0 |
What I wonder, though, is: how did get to be so absurdly high? And on my work box and home box both, even though they're rather different setups? (dual x86/Win vs. dual x64/Linux) If milkyway estimates are off, the DCF tries to compensate, and may get too high/low. If the project then fixes its estimates (or gets them wrong in the other direction!), you will get completely wrong estimates until the DCF manages to compensate it again :) Please use "Reply" or "Quote" buttons on posts, instead of "reply to this thread". Keep the posts linked together ("X is a reply to Y"). |
Send message Joined: 6 Sep 07 Posts: 66 Credit: 636,861 RAC: 0 |
It seems that the application remains in memory after the WU is finished, confirmed by BoincView which shows the system running other projects, not Milkyway any longer. TIA |
©2024 Astroinformatics Group