You must have a more powerful RETRY button than I have :-)
Well, I think I tested it at a time when the problem was developing gradually. I tested on a machine which had one Parkes PMPS XT task to upload - two files. While I was hitting retry to catch the log, one of the two files slipped away - but the other is still waiting.
BOINC logfile shows a changed situation:-( Not for the better AFAIC, now it doesn't give a reason for the problems, just whats happening to the upload attempt.
30/03/2015 22:44:22 | Einstein@Home | Started upload of PM0013_018B1_30_0_1
30/03/2015 22:44:23 | Einstein@Home | Backing off 03:20:48 on upload of PM0013_018B1_30_0_1
30/03/2015 22:47:07 | Einstein@Home | Started upload of PM0013_018B1_30_0_0
30/03/2015 22:47:07 | Einstein@Home | Started upload of PM0013_018B1_30_0_1
30/03/2015 22:47:08 | Einstein@Home | Backing off 05:12:25 on upload of PM0013_018B1_30_0_0
30/03/2015 22:47:08 | Einstein@Home | Backing off 04:27:22 on upload of PM0013_018B1_30_0_1
30/03/2015 22:47:11 | Einstein@Home | Started upload of PM0013_018B1_30_0_0
30/03/2015 22:47:11 | Einstein@Home | Started upload of PM0013_018B1_30_0_1
30/03/2015 22:47:12 | Einstein@Home | Backing off 05:50:45 on upload of PM0013_018B1_30_0_0
30/03/2015 22:47:12 | Einstein@Home | Backing off 03:52:49 on upload of PM0013_018B1_30_0_1
So it just shows its repeatedly backing off from the upload, but not why its backing off:-(
I'm not sure what to do to resolve this problem, the only other options seem to be, to complete and try with another WU or to abort the problem upload:-(
And I realy don't want to waste the time spent crunching that file:-(
Does anyone know where BOINC puts its output files for upload?
Maybe I can move them to have another try later?
As usual, the debug log flags - now just a GUI click away - are your friend. The upload/backoff is our old friend the 404 not found:
30/03/2015 23:35:09 | Einstein@Home | [http] [ID#1102] Received header from server: HTTP/1.1 404 Not Found
30/03/2015 23:35:09 | Einstein@Home | [http] [ID#1102] Info: HTTP error before end of send, stop sending
30/03/2015 23:35:09 | Einstein@Home | Backing off 05:53:16 on upload of PM0013_01611_196_2_0
I thought I'd reported that, but I'l check in the morning.
It isn't a case of where the file is located - there's also the question of how it's defined in client_state.xml. You would need to remove the reference (temporarily) as well, and that's tricky. Just leave it alone until the morning.
As usual, the debug log flags - now just a GUI click away - are your friend. The upload/backoff is our old friend the 404 not found:
30/03/2015 23:35:09 | Einstein@Home | [http] [ID#1102] Received header from server: HTTP/1.1 404 Not Found
30/03/2015 23:35:09 | Einstein@Home | [http] [ID#1102] Info: HTTP error before end of send, stop sending
30/03/2015 23:35:09 | Einstein@Home | Backing off 05:53:16 on upload of PM0013_01611_196_2_0
I thought I'd reported that, but I'l check in the morning.
It isn't a case of where the file is located - there's also the question of how it's defined in client_state.xml. You would need to remove the reference (temporarily) as well, and that's tricky. Just leave it alone until the morning.
Hi Richard,
Thanks, I'll leave it be for now.
So far I have 2 WU in the same state of play:-( And since I made the mistake of hitting update I also now have over 20 WU in my cache:-(
Looks as if I'm going to have to run E@H on its own and for at over 12 hours to clear up those tasks..
Be a real bummer if everything ends up sitting in the outbound queue..
In the past here I don't remember of ever having any problem with this once Bernd Machenschalk waves his magic server wand all of our WU's get uploaded and get those credits no matter how many we have waiting so keep on crunchin'
One of my machines has
)
One of my machines has managed to pull down a couple of fresh work units, but another has already reached the dreaded:
03/30/2015 14:00:24 | Einstein@Home | Not requesting tasks: too many uploads in progress
RE: Richard, You must have
)
Well, I think I tested it at a time when the problem was developing gradually. I tested on a machine which had one Parkes PMPS XT task to upload - two files. While I was hitting retry to catch the log, one of the two files slipped away - but the other is still waiting.
No luck here either (PDT)
)
No luck here either (PDT)
Still
)
Still getting
Yes, also unable to upload
)
Yes, also unable to upload here.
Yes it seems that the upload
)
Yes it seems that the upload handler is taking a break.
Hi All, BOINC logfile
)
Hi All,
BOINC logfile shows a changed situation:-( Not for the better AFAIC, now it doesn't give a reason for the problems, just whats happening to the upload attempt.
30/03/2015 22:44:22 | Einstein@Home | Started upload of PM0013_018B1_30_0_1
30/03/2015 22:44:23 | Einstein@Home | Backing off 03:20:48 on upload of PM0013_018B1_30_0_1
30/03/2015 22:47:07 | Einstein@Home | Started upload of PM0013_018B1_30_0_0
30/03/2015 22:47:07 | Einstein@Home | Started upload of PM0013_018B1_30_0_1
30/03/2015 22:47:08 | Einstein@Home | Backing off 05:12:25 on upload of PM0013_018B1_30_0_0
30/03/2015 22:47:08 | Einstein@Home | Backing off 04:27:22 on upload of PM0013_018B1_30_0_1
30/03/2015 22:47:11 | Einstein@Home | Started upload of PM0013_018B1_30_0_0
30/03/2015 22:47:11 | Einstein@Home | Started upload of PM0013_018B1_30_0_1
30/03/2015 22:47:12 | Einstein@Home | Backing off 05:50:45 on upload of PM0013_018B1_30_0_0
30/03/2015 22:47:12 | Einstein@Home | Backing off 03:52:49 on upload of PM0013_018B1_30_0_1
So it just shows its repeatedly backing off from the upload, but not why its backing off:-(
I'm not sure what to do to resolve this problem, the only other options seem to be, to complete and try with another WU or to abort the problem upload:-(
And I realy don't want to waste the time spent crunching that file:-(
Does anyone know where BOINC puts its output files for upload?
Maybe I can move them to have another try later?
Regards
Cliff,
Been there, Done that, Still no damm T Shirt.
As usual, the debug log flags
)
As usual, the debug log flags - now just a GUI click away - are your friend. The upload/backoff is our old friend the 404 not found:
30/03/2015 23:35:09 | Einstein@Home | [http] [ID#1102] Received header from server: HTTP/1.1 404 Not Found
30/03/2015 23:35:09 | Einstein@Home | [http] [ID#1102] Info: HTTP error before end of send, stop sending
30/03/2015 23:35:09 | Einstein@Home | Backing off 05:53:16 on upload of PM0013_01611_196_2_0
I thought I'd reported that, but I'l check in the morning.
It isn't a case of where the file is located - there's also the question of how it's defined in client_state.xml. You would need to remove the reference (temporarily) as well, and that's tricky. Just leave it alone until the morning.
RE: As usual, the debug log
)
Hi Richard,
Thanks, I'll leave it be for now.
So far I have 2 WU in the same state of play:-( And since I made the mistake of hitting update I also now have over 20 WU in my cache:-(
Looks as if I'm going to have to run E@H on its own and for at over 12 hours to clear up those tasks..
Be a real bummer if everything ends up sitting in the outbound queue..
Damn power bill is going to go up again:-/
Regards,
Cliff,
Been there, Done that, Still no damm T Shirt.
In the past here I don't
)
In the past here I don't remember of ever having any problem with this once Bernd Machenschalk waves his magic server wand all of our WU's get uploaded and get those credits no matter how many we have waiting so keep on crunchin'