I just had 16 0.17 WU's with failed downloads.

<edit>
Here is the error from the log:

1/27/2009 3:15:40 PM|Milkyway@home|Sending scheduler request: To fetch work. Requesting 230401 seconds of work, reporting 0 completed tasks
1/27/2009 3:15:46 PM|Milkyway@home|Scheduler request completed: got 16 new tasks
1/27/2009 3:15:48 PM|Milkyway@home|Started download of milkyway_0.17_windows_intelx86.exe
1/27/2009 3:15:48 PM|Milkyway@home|Started download of parameters-86-modified.txt
1/27/2009 3:15:49 PM|Milkyway@home|Finished download of parameters-86-modified.txt
1/27/2009 3:15:49 PM|Milkyway@home|Started download of nm_s86_l31_search_parameters_25954_1233087111
1/27/2009 3:15:49 PM|Milkyway@home|[error] MD5 check failed for parameters-86-modified.txt
1/27/2009 3:15:49 PM|Milkyway@home|[error] expected 8bfb4c1453a343a77951b3c40990667c, got 491e0836fdebfa7775324a312565eece
1/27/2009 3:15:49 PM|Milkyway@home|[error] Checksum or signature error for parameters-86-modified.txt

I just had 16 0.17 WU's with failed downloads.


Here is the error from the log:

1/27/2009 3:15:40 PM|Milkyway@home|Sending scheduler request: To fetch work. Requesting 230401 seconds of work, reporting 0 completed tasks
1/27/2009 3:15:46 PM|Milkyway@home|Scheduler request completed: got 16 new tasks
1/27/2009 3:15:48 PM|Milkyway@home|Started download of milkyway_0.17_windows_intelx86.exe
1/27/2009 3:15:48 PM|Milkyway@home|Started download of parameters-86-modified.txt
1/27/2009 3:15:49 PM|Milkyway@home|Finished download of parameters-86-modified.txt
1/27/2009 3:15:49 PM|Milkyway@home|Started download of nm_s86_l31_search_parameters_25954_1233087111
1/27/2009 3:15:49 PM|Milkyway@home|[error] MD5 check failed for parameters-86-modified.txt
1/27/2009 3:15:49 PM|Milkyway@home|[error] expected 8bfb4c1453a343a77951b3c40990667c, got 491e0836fdebfa7775324a312565eece
1/27/2009 3:15:49 PM|Milkyway@home|[error] Checksum or signature error for parameters-86-modified.txt

I think that file got changed with the newer searches... that might have caused the problem. Is it still happening?

---

I just had 16 0.17 WU's with failed downloads.

<edit>
Here is the error from the log:

1/27/2009 3:15:40 PM|Milkyway@home|Sending scheduler request: To fetch work. Requesting 230401 seconds of work, reporting 0 completed tasks
1/27/2009 3:15:46 PM|Milkyway@home|Scheduler request completed: got 16 new tasks
1/27/2009 3:15:48 PM|Milkyway@home|Started download of milkyway_0.17_windows_intelx86.exe
1/27/2009 3:15:48 PM|Milkyway@home|Started download of parameters-86-modified.txt
1/27/2009 3:15:49 PM|Milkyway@home|Finished download of parameters-86-modified.txt
1/27/2009 3:15:49 PM|Milkyway@home|Started download of nm_s86_l31_search_parameters_25954_1233087111
1/27/2009 3:15:49 PM|Milkyway@home|[error] MD5 check failed for parameters-86-modified.txt
1/27/2009 3:15:49 PM|Milkyway@home|[error] expected 8bfb4c1453a343a77951b3c40990667c, got 491e0836fdebfa7775324a312565eece
1/27/2009 3:15:49 PM|Milkyway@home|[error] Checksum or signature error for parameters-86-modified.txt

I think that file got changed with the newer searches... that might have caused the problem. Is it still happening?

I reset the project and it just downloaded some fresh WU's that seem to be crunching along, although 9+ hour completion time a piece puzzles me, but I will let them run. I'll post again if something else happens.

Thanks

@Beau,

One of my machines always resets to a 9 hour completion estimate when I do a reset. It will come down as you do some WUs.

---

Calm Chaos Forum...Join Calm Chaos Now

@Beau,

One of my machines always resets to a 9 hour completion estimate when I do a reset. It will come down as you do some WUs.

Yes, you are absolutely correct and the time is comming down to a typical level. It just sort of startled me a bit to suddenly see 9 hours!

Thanks for your reply!

Beau

Shouldn't we be up to v.20 or so now? I mean it's been a day and no updates. Someone must be ill. :P

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

I am waiting for .21 you know the black jack game. Then I will recompile...

DD,

---

I am waiting for .21 you know the black jack game. Then I will recompile...

DD,

Please don't :/ The last time I went to Vegas I was beating the credit card machine for not giving me cash over my credit limit. That card scraping is addictive! :P

---

FWIW, I am seeing this result on .17 WUs:

<core_client_version>6.4.5</core_client_version>
<![CDATA[
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1233321225.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
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1233321225.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

</stderr_txt>
]]

Jim

FWIW, I am seeing this result on .17 WUs:

6.4.5

Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1233321225.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
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1233321225.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


]]

Jim

All of them, or is this a recent problem?

---

I have many .16 WUs for my Intel Mac and I don't see this in them. I have just 2 results for my XP machine and I see this in both of them.

Jim

I had at least 30 of them yesterday on Vista 32bit, with state: valid.

But as of today they seem to be OK :

<core_client_version>6.1.0</core_client_version>
<![CDATA[
<stderr_txt>

</stderr_txt>
]]>


Kurt

edit: 0.17 !

---

The state was valid on both of the .17 WUs, so I guess they generated data.

My third XP result has the same result.

Jim

FWIW, I am seeing this result on .17 WUs:

<core_client_version>6.4.5</core_client_version>
<![CDATA[
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1233321225.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
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1233321225.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

</stderr_txt>
]]

Jim

All of them, or is this a recent problem?

Apparently these are harmless messages:from the boinc forums

I see the time estimates for the 0.17 |36 WUs is high.

The normal |34 and |35 crunch in about 30 minutes, and the time to completion estimates reflect this. But the |36 WUs have estimates to completion on the same rig of 6 hours 50 seconds.

I assume the real crunching times will be much shorter than the estimates, and the credit awarded will reflect the increased crunch time (if it happens)?

I see the time estimates for the 0.17 |36 WUs is high.

The normal |34 and |35 crunch in about 30 minutes, and the time to completion estimates reflect this. But the |36 WUs have estimates to completion on the same rig of 6 hours 50 seconds.

I assume the real crunching times will be much shorter than the estimates, and the credit awarded will reflect the increased crunch time (if it happens)?

I just noticed one of those on my P4M, went from just under two hour to estimating 25 hours.

---

Calm Chaos Forum...Join Calm Chaos Now

I think Dave might have upgraded his windows box and missed something when he recompiled BOINC. I'll have to ask him about it.

Hmmm...

Yep, that's been a common theme lately! ;-)

If he compiled it with the latest version of Visual Studio, the you lose NT4 and 9x compatability. :-(

VS2005 is the last one to have it, IIRC.

So the next question is, is it kosher to set up an app_info to specify v0.14 (stock) to run for the current tasks?

Alinator

Any new for our venerable old crunchers ?

The new |36, |38 and |39 WUs are taking quite a lot more time to crunch (time per WU is 32% longer) but the additional credit awarded is 8.6% (based on the standard 27.93 CC award).

The new |36, |38 and |39 WUs are taking quite a lot more time to crunch (time per WU is 32% longer) but the additional credit awarded is 8.6% (based on the standard 27.93 CC award).

Yeah I'm trying to figure out new credit function that takes into account multiple streams. Workunits named nm_s79_XXX , nm_s82_XXX, nm_s86_XXX should be running in the same amount of time as they were before, however the nm_s20_XXX and nm_s21_XXX should be a bit longer. I tweaked the credit for these a bit in the latest searches l40 and l41, so hopefully they should better reflect the increase in CPU time.

---