So I sat and watched a w/u complete...... sad I know. It uploaded the 5th trickle ok. Then came to the end of processing and produced a small file to upload, which uploaded ok. The w/u status changed Ready to report ?. Which it did.

All very satisfying after 20 days. We dont all have super computers.....

But a day later the w/u is still showing as "In progress" on the "tasks for computer" page.

https://www.cpdn.org/result.php?resultid=21957285

The computer it came from only has 1 cpdn task left to do before its harddisk is upgraded.
Has the server just not caught up yet or is it another fiendish way of losing a w/u at 100%
Ta
Nairb

I've had several of these across a few PCs. None lately though. I'm not sure whether there is some congestion/contention on the server when the reports happen, or what. Maybe 2% of my completed models have done this. I don't think there is anything you can do about it. I've had it happen a few times when a task reported around the time that the credit script is running on the server. Yours may have transmitted in that window (which is weekly, late Wed/early Thu UK time).

That task will time out in a year and may be reissued then, which is probably ridiculous. The only way for it to be reissued from that work unit before that is if you detach and then reattach the computer to cpdn. Of course you wouldn't want any cpdn tasks on that PC at the time you detached/reattached. It's up to you if you want to do that. No big deal if you don't. The completed (but not acknowledged as completed by the server) task will be labelled as abandoned on your list of tasks after the detach/reattach and a new task from that work unit would be ready to go out to another computer. Like I said, it's completely up to you if you want to go through that process.

Sorry about that...it's a bummer when it happens.

Thanks for the answer..... So it seems there is another way to lose a w/u at 100%. Without any warning a w/u can be wasted on the last "ready to report" communication. And all is lost................... along with any remaining sense of satisfaction which is all there really is from participating in these projects.
I will let the remaining 5 run to completion. Who knows - a couple of w/u might actually end up being useful.

The last zip upload should have gone to the server OK, so all is not lost.
It's just that the completion will not be registered on your tasks page, so you have to remember that mentally.

The last zip upload should have gone to the server OK, so all is not lost.
It's just that the completion will not be registered on your tasks page, so you have to remember that mentally.

Ok, so the w/u should be valid for the scientists but just shows "in progress" on the tasks page. Which is a better outcome.

It must be possible to run a script to update the tasks page. But if the task has finished ok I guess there is little incentive to do this.

I've had several of these across a few PCs. None lately though. I'm not sure whether there is some congestion/contention on the server when the reports happen, or what. Maybe 2% of my completed models have done this. I don't think there is anything you can do about it. I've had it happen a few times when a task reported around the time that the credit script is running on the server. Yours may have transmitted in that window (which is weekly, late Wed/early Thu UK time).

That task will time out in a year and may be reissued then, which is probably ridiculous. The only way for it to be reissued from that work unit before that is if you detach and then reattach the computer to cpdn. Of course you wouldn't want any cpdn tasks on that PC at the time you detached/reattached. It's up to you if you want to do that. No big deal if you don't. The completed (but not acknowledged as completed by the server) task will be labelled as abandoned on your list of tasks after the detach/reattach and a new task from that work unit would be ready to go out to another computer. Like I said, it's completely up to you if you want to go through that process.

Sorry about that...it's a bummer when it happens.

Is there no true handshake? When the client fails to receive an ack it should resend the WU (and, naturally, the server should be able to deal with duplicates already).

Resend isn't used here because of the nature of climate models.
If a computer can't get it right the first time, for whatever reason, then it's put back into the queue for the next computer to try.
Of which there are thousands, so it's not a big deal for the researchers.

Resend isn't used here because of the nature of climate models.
If a computer can't get it right the first time, for whatever reason, then it's put back into the queue for the next computer to try.
Of which there are thousands, so it's not a big deal for the researchers.

Fair enough, it’s not a problem I’ve ever encountered - although blaming it on the client when the example given was a server fault ... 😛

OK, in that example, the process is way beyond the point of where a Resend is needed.
All of the data has reached the various servers, and is being dealt with; then one of the servers has a sneezing attack, and doesn't see one packet of data being moved past it, so the packet doesn't get ticked off on a task page.

OK, in that example, the process is way beyond the point of where a Resend is needed.
All of the data has reached the various servers, and is being dealt with; then one of the servers has a sneezing attack, and doesn't see one packet of data being moved past it, so the packet doesn't get ticked off on a task page.

OK, I submit - too much work for too small a problem :-)