Only 60% of WUs are Credited

[arisu]

But that doesn't tell what percentage are using the v8 client. If only 5% of Windows users are on v8 and the rest are on v7, then each user dumping a WU by rebooting without pausing first isn't as critical as if half of all Windows users are on v8.

[Joe_H]

I hit submit before adding the note I meant to about that. Just as a note, it was a problem with the v7 client at times. I would have to check the v7 change logs to see if/when that was ever fixed.

[muziqaz]

Is it possible that Windows is v7 and win64 is v8

[calxalot]

I think only Joseph knows.

[muziqaz]

I think he mentioned that before

Also, v7 is 32bit, V8 - 64bit only

[arisu]

So approximately 21% of FAH's entire folding power is running on systems that dump WUs if not paused before rebooting. That's got to be a lot of lost work, and if the bug in viewtopic.php?t=42577 is still around then that makes it even worse.

Btw the OS page points to an FAQ about FLOPS https://foldingathome.org/faqs/flops/ which is empty and essentially a dead link.

[muziqaz]

Yes, we painfully know

[arisu]

Why is such a problem not a top priority for the developers and fixed immediately? Is there a reason for the team's languor, or is the fix not simple because there some sort of amassed technical debt that has to be worked on first? Are they short on developers and in need of donations?

I don't like the idea that my electricity bills are being spent redoing scientific work that was already done but lost due to what seems like a simple bug.

Even if there is something that makes the bug harder to fix than I expect, at least an emergency v8 release could be made that forcibly terminates the client when a shutdown is detected without asking the cores to create a new checkpoint and terminate themselves. It would be a lot better to lose one checkpoint worth of progress than one work unit.

[muziqaz]

There is only one developer. GitHub is your friend. Fahclient V8 is open source. There are many issues with client and infrastructure.
It is possible that fahcores are at fault as well, and that is another can of worms

[arisu]

There is an unreleased commit that changes something about the terminate order.
I don’t know if anyone else has tested it.

https://github.com/FoldingAtHome/fah-cl ... 429c9444cc

I didn't even notice this until now. That should fix the problem of Windows WUs being dumped on reboot, assuming that the client doesn't dump a WU when it itself was terminated (otherwise there would be no point to write CPU checkpoints every 5 minutes). Hopefully 8.4.10 is released very soon.

There is only one developer. GitHub is your friend. Fahclient V8 is open source. There are many issues with client and infrastructure.
It is possible that fahcores are at fault as well, and that is another can of worms

The infrastructure is not open source, though.

And yeah, the cores are also at fault (I posted about that earlier in this thread). There's only so much a client can do when the cores don't communicate with it properly. Maybe one day in the future, the cores will also be open sourced, leaving only a small anti-cheat library closed (if it's even necessary, because decent server-side heuristics would prevent most if not all cheating intended to increase PPD by anyone who isn't already an expert in bioinformatics). I don't know about the other cores, but a8 looks to me like it is mostly cbang-flavored glue between mdrun and the client.

[muziqaz]

As I said client issues can be discussed on GitHub. Dev does not read this forum

[arisu]

It's mostly an issue with the cores (the excessive dumping in general). The client can only do so much if the cores are communicating the wrong information to them. As the cores are not open and I cannot find any bug tracker for them, I'll just let the dev(s) for the cores get to it whenever they wish.

This specific issue with the cores that the client happens to be able to work around has already been posted about on GitHub a while ago, so I guess the dev is already aware of it.

[muziqaz]

It's mostly an issue with the cores (the excessive dumping in general). The client can only do so much if the cores are communicating the wrong information to them. As the cores are not open and I cannot find any bug tracker for them, I'll just let the dev(s) for the cores get to it whenever they wish.

This specific issue with the cores that the client happens to be able to work around has already been posted about on GitHub a while ago, so I guess the dev is already aware of it.

I know, that's why I suggested moving to github

[markhl]

Agree that FAH should always resume from the last checkpoint. I expect FAH and other volunteer computing projects to checkpoint fairly often, every hour or so. When I shut down, I expect to lose work since the last checkpoint. But not to lose the whole WU!

The great Web Control interface on v8 made it easier for me to find that I was losing WUs, but it may also have happened on v7. So, I may have lost many WUs ...

How can we let new users know that they should pause before shutdown? I happened to open Web Control to see the issue. And I happened to browse the forum and find that recommendation - about three years after I had started running FAH!

[muziqaz]

V7 didn't have that problem.