clGetPlatformIDs() returned -1001

[tripplehelix]

@bikeaddict

That’s fascinating, so nothing I've done has actually counted? I'll power down my Pi. I was under the impression that I was helping as I was receiving points. Very sad to see, unfortunately I don't have any other free hardware to run folding@home on. I'll repurpose this Pi.

[bikeaddict]

This particular WU appears to have been counted. But it was returned 1.5 days later than the researcher wanted.

It's possible that the system did regenerate the WU to be reassigned to another client, but it wasn't sent out before you returned it. There could be a process that removes reassigned WUs that miss the timeout but come in before they expire. Or maybe the WU was actually sent out and run again, but that report doesn't show the second one being completed.

There is still a problem with the assignment process that needs to be addressed. Any hardware that is taking multiple days to finish a WU and frequently missing the timeout should only be getting assigned smaller 1-day timeout WUs.

[tripplehelix]

Surely they should base future WU's based on what the hardware has managed in the past. A quick speed test of the machine the first time it connects to folding@home would suffice.

[Joe_H]

Surely they should base future WU's based on what the hardware has managed in the past. A quick speed test of the machine the first time it connects to folding@home would suffice.

That would require keeping statistical data of tens of thousands different systems and an increase in complexity to the assignment process that a single developer is not going to be able to support. That "quick speed test" could then be invalidated by the next configuration change made by the user or by the user not folding full time.

They do take reports of hardware not being able to consistently complete WUs from various projects and do have assignment parameters to keep a project from being assigned to ARM for instance. Or larger GPU based projects may only get assigned to th more powerful GPUs.

[toTOW]

It's possible that the system did regenerate the WU to be reassigned to another client, but it wasn't sent out before you returned it.

Yes very likely. This process depends on the pressure put on the FAH system and this particular project or hardware combination ...

For this particular trajectory :
- WU has been assigned to a client that failed it immediately
- WU has been set out to tripplehelix
- WU expired and has been marked for resend
- tripplehelix returned a valid result before the WU has been reassigned, so it has been marked as valid and it has been used to create next WU
- next WU has been sent and completed

In this case, the work sent after timeout has not been wasted, but if there are a lot of clients fighting for this kind of work, it would gave been wasted ...