Unusually low PPD on project 16927?

[bruce]

Agreed.

In the cases involving 169xx, the slowest assignments are in the expected range for my hardware. When I happen to get a fast assignment, it's just an extra bonus.

[zotric]

Thanks for the response, Bruce.
As you will see from my update there are unexpected (to me anyway) errors in the log file.
I've stopped using the CPU for now so I've just put in as much information as I can in case anyone finds it useful.
Answers below:

Yes, WUs from p169xx are highly variable but that doesn't seem to be your real problem.
-- Agreed, I think, based on my subsequent findings and your comments. The logged errors are a puzzle though. Also the fact that the system abandoned the WU.

Where are you looking to see "the advertised number of cores"?
-- I meant the number of threads set in FAHControl

Are you adjusting the number of assigned threads manually? If so, when do you do so? Look back through your logs and determine how many cores were configured by the slot that initiated FAHClient's download of that project?
-- I think I originally started the WU with a low thread count for testing purposes then increased it.

A slot that's configured for 4 CPUs will download WUs that cannot use more that 4 threads. For any slot that's going to download a new WU soon, increase the number allocated to some realistic number that might actually be available.
-- I think the system behaviour is correct. I just did not know that it did this. A case of RTFM?

[bruce]

I'm not sure I'd call it RTFM, because it's probably not anywhere in a "manual" that's easy to find. Nevertheless, FAHClient tells the server what resources you're offering and it assigns a WU that will run on them (or less).