<core_client_version>6.6.20</core_client_version>
<![CDATA[
<message>
WU download error: couldn't get input files:
<file_xfer_error>
<file_name>params_052909_084735_0.ini</file_name>
<error_code>-224</error_code>
<error_message>file not found</error_message>
</file_xfer_error>

Don't know what happened there. Other projects are downloading without issue, and cosmo did shortly afterwards. <fx>shrugs</fx>

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

The DL errors (missing files) have been going on for months at Cosmo.

---

me@rescam.org

The DL errors (missing files) have been going on for months at Cosmo.

I even wished that someone would fix them...

---

The DL errors (missing files) have been going on for months at Cosmo.

I even wished that someone would fix them...

Wishing has also been going on for months. ;)

---

me@rescam.org

I lately got the impression, that those "download failed" errors are connected to a missed deadline of the first one who received a result of that workunit.

I lately got the impression, that those "download failed" errors are connected to a missed deadline of the first one who received a result of that workunit.

Maybe they are just deleting after they've first been sent. If that's the case, perhaps it is something as simple as they need to leave the task files there until the workunit is validated or reaches one of the limits.

---

I lately got the impression, that those "download failed" errors are connected to a missed deadline of the first one who received a result of that workunit.

That is certainly my observation also, over the past several months.
The process seems to be that an initial unit is sent (apparently) to one computer, but doesn't arrive - it is a "ghost" unit.
15 days later, the unit is "timed out - no response" and, over the next hour or two, further units are prepared and sent to other computers - it is these which are seen as giving the "error which downloading" or exit status -186 (0xffffffffffffff46) message for the task.
So eventually this process causes a "Too many error results. Too many total results" message to be attached to the WU.
The source of all this mayhem seems to lie in the initial (ghost) unit.
I suspect the problem hasn't been "fixed" because it causes no harm to anyone while other, more urgent, problems have had to be dealt with.

I lately got the impression, that those "download failed" errors are connected to a missed deadline of the first one who received a result of that workunit.

That is certainly my observation also, over the past several months.
The process seems to be that an initial unit is sent (apparently) to one computer, but doesn't arrive - it is a "ghost" unit.
<snip>
The source of all this mayhem seems to lie in the initial (ghost) unit.
I suspect the problem hasn't been "fixed" because it causes no harm to anyone while other, more urgent, problems have had to be dealt with.

I was in a position to test something just now. I really don't think there are "ghost" tasks on the initial download...

Take a look at my host by clicking here. You'll notice that it took me requesting 10 tasks to get 3 of them that would download. I then did a reset project and attempted another 10 downloads, 5 of which had problems downloading and 5 that I downloaded fine. I manually aborted 2 out of the 5 that I downloaded, leaving me with 3 real tasks to work on. However, you'll note that the server still thinks I have the 3 that were on the system when I did a reset project. Those will time out and then there'll likely be download errors for anyone else who tries to download them. What will be curious to see is if the 2 aborted tasks also cause download errors.

The moral of the story though is: The likely cause of this is because people are seeing very long processing times and very high memory consumption and are basically saying "forget this" and resetting project. I'm using an older BOINC version (5.8.16), so someone with 6.x.x version of BOINC should try doing the same to make sure that newer versions of BOINC behave the same way when there's a reset project.

---

Well, the three tasks that I suspected would have problems did have problems. All three had nothing but download errors. The tasks that I aborted, well both got resent properly, but one person also decided it wasn't worth it and it gave a timeout, which then proceeded to cause the download errors.

That said, it doesn't seem that the project gives a rip one way or the other about this... They seem to be slap-happy because they're getting the data they need for Planck, so who cares I suppose...

I lately got the impression, that those "download failed" errors are connected to a missed deadline of the first one who received a result of that workunit.

That is certainly my observation also, over the past several months.
The process seems to be that an initial unit is sent (apparently) to one computer, but doesn't arrive - it is a "ghost" unit.
<snip>
The source of all this mayhem seems to lie in the initial (ghost) unit.
I suspect the problem hasn't been "fixed" because it causes no harm to anyone while other, more urgent, problems have had to be dealt with.

I was in a position to test something just now. I really don't think there are "ghost" tasks on the initial download...

Take a look at my host by clicking here. You'll notice that it took me requesting 10 tasks to get 3 of them that would download. I then did a reset project and attempted another 10 downloads, 5 of which had problems downloading and 5 that I downloaded fine. I manually aborted 2 out of the 5 that I downloaded, leaving me with 3 real tasks to work on. However, you'll note that the server still thinks I have the 3 that were on the system when I did a reset project. Those will time out and then there'll likely be download errors for anyone else who tries to download them. What will be curious to see is if the 2 aborted tasks also cause download errors.

The moral of the story though is: The likely cause of this is because people are seeing very long processing times and very high memory consumption and are basically saying "forget this" and resetting project. I'm using an older BOINC version (5.8.16), so someone with 6.x.x version of BOINC should try doing the same to make sure that newer versions of BOINC behave the same way when there's a reset project.

---

Another download fail today...

Nobody has crunched it yet, download failures, four of, and a "timed out - no response" message, so they presumably got it to download.

In case anyone is looking for the problem...

Name wu_072109_063205_4_0_4
Workunit 6575285
Created 6 Aug 2009 15:23:16 UTC
Sent 6 Aug 2009 15:52:04 UTC
Received 6 Aug 2009 16:01:51 UTC
Server state Over
Outcome Client error
Client state Downloading
Exit status -186 (0xffffffffffffff46)
Computer ID 2332
Report deadline 21 Aug 2009 15:52:04 UTC
CPU time 0
stderr out <core_client_version>6.6.20</core_client_version>
<![CDATA[
<message>
WU download error: couldn't get input files:
<file_xfer_error>
<file_name>params_072109_063205_4.ini</file_name>
<error_code>-224</error_code>
<error_message>file not found</error_message>
</file_xfer_error>

</message>
]]>

Validate state Invalid
Claimed credit 0
Granted credit 0
application version 2.16

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

The Large number of WU that fail due to download error`s has got silly.
Right now on my first `tasks for user` page, 13 of the 20 are DL errors,
and the problem has this last 40 DL atempts made me think how long is it going to be before this blocks up the system

The Large number of WU that fail due to download error`s has got silly.
Right now on my first `tasks for user` page, 13 of the 20 are DL errors,
and the problem has this last 40 DL atempts made me think how long is it going to be before this blocks up the system

Well, nearly all of the systems that had the timeout were systems that belong to people who joined the project within the past month. This is more evidence that new people attach and download tasks, then become shocked / upset at the amount of time the task takes and the amount of memory it consumes, so they issue a reset project, which does not report that the tasks have been abandoned.

However, this project's leadership is non-existent, primarily due to enough data being processed by long-term members / those dedicated to the science of the project. The incoming data and few "bugs" appears to be lulling them into thinking everything is going great. Anshul said that after May 17th he'd work on various things. Well, it's about as bad as Windows 95, which was called Windows xx95 (unsure of what century)... Most colleges and universities here in the United States will be starting back up within the next 3-4 weeks. This means that there will be more school work to do, and even less time to spend on the project's issues. That's fine for Anshul, and I applaud him for that. The responsibilty for how unresponsive this project is to user-reported issues ultimately rests with Ben, who seems oblivious to just how much the increased processing time / memory usage is driving away new volunteers.

---

I stopped running this project a bit ago because of the download problems. I thought I would try again and put a couple of cores on it. Now I find that the DL errors are even greater and now there are large memory problems. I must conclude that if the project admin's do not care about the project, why should I? So I am moving the cores back to Milkyway. Too bad actually. Cheers!

---

What you say makes sence up to a point. I run 6.6.36 (64bit) on Win 7 and have had only three uw's with .ini file missing. Maybe some one from Cosmology would like to explain!

---

"All man born has a right to life and no man born has the right to take that life"

The problem is that each result that has not been successful or has not been returned at all produces 4 results with download errors. Only the first one who downloads a result receives his workunit.

It is 4 download errors, even though it should be only 3 (limited by the WU setup), but an ancient bug in BOINC makes the scheduler send it out always once too often.

So a "max # of error/total/success tasks 1, 1, 1" setup would reduce the total number of download errors ... not deleting the workunit on the server after the first successful download would reduce those errors even more though ;-)

Another here, same junk as before. Two others have got it, completed it and been credited. It has gone out again.

Brian, I've been a member here more or less from the start, but with a low percentage quota, (now anyway).

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Yes, if the first to download the wu makes an `error` of it,
like one of my pc`s has recently,
its download errors for everyone after the 2 mashed WU`s got reported by my putrid pc.

Unfortunatly for me it looks like my trusty old athlon xp 2500 mobile is failing,
Its had quite a life,
bought off ebay and overclocked (not overvolted) from the day it arrived,
it has been on boinc in 3 pc`s for years,
i have no idea how many credits it has earned,
I hope it gets to spend them when when it finaly gets to silicon heaven :)
But not quite yet, i`le just have to reduce the fsb 1 Mhz a month or so :)
"I`me not dead yet . . . "
thunk.
9d.
,`,`,`,`,`,

I live 45 miles from Champaign/Urbana - would you like me to come and fix the download problem! I'll do it for free.

I live 45 miles from Champaign/Urbana - would you like me to come and fix the download problem! I'll do it for free.

Well now there is an offer I wish the admin`s here would take.
(if allowable, legal stuff, you know how it is :()

The download problems kill boinc-6.6.40 on my machine (gentoo linux), so I've detached my fastest machine from this project. I won't put it back until this problem is solved, as I need v. 6.6.x for QCN to run properly...
Not that one more cruncher leaving changes anything, I just wonder why we don't even get any news about them solving these problems?