Welcome to MilkyWay@home

post milkyway_windows_intelx86 problems here

Message boards : Number crunching : post milkyway_windows_intelx86 problems here
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · Next

AuthorMessage
mycal

Send message
Joined: 13 Jan 08
Posts: 19
Credit: 820,482
RAC: 0
Message 7239 - Posted: 2 Dec 2008, 10:50:00 UTC

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
ID: 7239 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
jasper

Send message
Joined: 20 Jun 08
Posts: 3
Credit: 649,825
RAC: 0
Message 7249 - Posted: 2 Dec 2008, 18:32:12 UTC - in response to Message 7228.  

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

ID: 7249 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Chris S
Avatar

Send message
Joined: 20 Sep 08
Posts: 1391
Credit: 203,563,566
RAC: 0
Message 7255 - Posted: 2 Dec 2008, 19:57:20 UTC

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>
<![CDATA[
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228200585.000000
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
No heartbeat from core client for 31 sec - exiting
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228200585.000000
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

</stderr_txt>
]]>
ID: 7255 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Mr Mystery

Send message
Joined: 21 Nov 08
Posts: 90
Credit: 2,601
RAC: 0
Message 7259 - Posted: 2 Dec 2008, 20:07:19 UTC - in response to Message 7255.  
Last modified: 2 Dec 2008, 20:14:31 UTC

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>
<![CDATA[
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228200585.000000
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
No heartbeat from core client for 31 sec - exiting
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228200585.000000
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

</stderr_txt>
]]>


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.
ID: 7259 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Scratty@SETI.USA

Send message
Joined: 20 Feb 08
Posts: 8
Credit: 9,928,369
RAC: 0
Message 7283 - Posted: 2 Dec 2008, 21:56:51 UTC

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
ID: 7283 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Warren B. Rogers

Send message
Joined: 24 Jan 08
Posts: 6
Credit: 7,367,832
RAC: 0
Message 7396 - Posted: 4 Dec 2008, 1:36:44 UTC

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
ID: 7396 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile JLDun
Avatar

Send message
Joined: 17 Nov 07
Posts: 77
Credit: 117,183
RAC: 0
Message 7417 - Posted: 4 Dec 2008, 8:01:31 UTC - in response to Message 7396.  

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?
ID: 7417 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
jasper

Send message
Joined: 20 Jun 08
Posts: 3
Credit: 649,825
RAC: 0
Message 7418 - Posted: 4 Dec 2008, 8:27:25 UTC - in response to Message 7249.  

...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?
ID: 7418 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile Logan
Avatar

Send message
Joined: 15 Aug 08
Posts: 163
Credit: 3,876,869
RAC: 0
Message 7420 - Posted: 4 Dec 2008, 8:55:47 UTC

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)
ID: 7420 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Chris S
Avatar

Send message
Joined: 20 Sep 08
Posts: 1391
Credit: 203,563,566
RAC: 0
Message 7421 - Posted: 4 Dec 2008, 11:27:09 UTC

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
ID: 7421 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile DoctorNow
Avatar

Send message
Joined: 28 Aug 07
Posts: 146
Credit: 10,545,490
RAC: 9,637
Message 7426 - Posted: 4 Dec 2008, 13:11:24 UTC - in response to Message 7421.  
Last modified: 4 Dec 2008, 13:11:57 UTC

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.

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.

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
ID: 7426 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
John Clark

Send message
Joined: 4 Oct 08
Posts: 1734
Credit: 64,228,409
RAC: 0
Message 7428 - Posted: 4 Dec 2008, 13:23:37 UTC

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.
ID: 7428 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
ebahapo
Avatar

Send message
Joined: 6 Sep 07
Posts: 66
Credit: 636,861
RAC: 0
Message 7431 - Posted: 4 Dec 2008, 16:25:45 UTC - in response to Message 7420.  

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

ID: 7431 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Nicolas
Avatar

Send message
Joined: 19 Nov 07
Posts: 29
Credit: 3,353,124
RAC: 0
Message 7434 - Posted: 4 Dec 2008, 16:51:53 UTC - in response to Message 7431.  

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").
ID: 7434 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Dorphas

Send message
Joined: 5 Dec 07
Posts: 6
Credit: 1,033,816
RAC: 0
Message 7448 - Posted: 4 Dec 2008, 20:37:26 UTC

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????
ID: 7448 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Chris S
Avatar

Send message
Joined: 20 Sep 08
Posts: 1391
Credit: 203,563,566
RAC: 0
Message 7452 - Posted: 4 Dec 2008, 21:48:02 UTC

Windoze V0.7 auto-downloaded on my pc at 16.00 UK time
Don't drink water, that's the stuff that rusts pipes
ID: 7452 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Dave

Send message
Joined: 25 Nov 08
Posts: 1
Credit: 233,264
RAC: 0
Message 7474 - Posted: 5 Dec 2008, 7:08:11 UTC

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.
ID: 7474 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
jasper

Send message
Joined: 20 Jun 08
Posts: 3
Credit: 649,825
RAC: 0
Message 7502 - Posted: 6 Dec 2008, 11:39:16 UTC - in response to Message 7426.  

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)
ID: 7502 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Nicolas
Avatar

Send message
Joined: 19 Nov 07
Posts: 29
Credit: 3,353,124
RAC: 0
Message 7511 - Posted: 6 Dec 2008, 19:00:26 UTC - in response to Message 7502.  

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").
ID: 7511 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
ebahapo
Avatar

Send message
Joined: 6 Sep 07
Posts: 66
Credit: 636,861
RAC: 0
Message 7512 - Posted: 6 Dec 2008, 19:58:03 UTC

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

ID: 7512 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Previous · 1 · 2 · 3 · 4 · Next

Message boards : Number crunching : post milkyway_windows_intelx86 problems here

©2024 Astroinformatics Group