TPF value in Machines and Work Units section takes quite some time to normalise and become accurate

[muziqaz]

Real TPF value is 30-31s
10% of WU done and displayed TPF is at 34s (It started at 37s at 1%).
20% of WU done and displayed TPF is at 32s
26% - still 32s
33% - finally 31s
Here are the screenshots of solid 30s TPF in the logs

Somehow I remember this was reported by me before, but I cannot find anything in open and closed issues (checked both client and web control github). Maybe it was mentioned in general.
Anyways, if we could get accurate TPF representation after 1st 3% that would be great. And TPF value ideally should be calculated from 3 frames as an average.
And I think there was a request to have minimum TPF value in Work Units section (barring some extremes due to clock skew or something).

[jcoffland]

It really depends on your idea of accurate. The client averages all of the frames. In that sense it is accurate. I suspect that the first frame generally takes longer. It then takes some time for this longer frame to get averaged out. One solution would be to throw out the first frame after some time. Or maybe even just throw out the measurement of the first part of the first frame.

[muziqaz]

But you can see in my screenshot, that all of the frame times in the log are exactly 30s. So even if fahclient is averaging all the frames, whatever it is showing in Machines and WU section is still incorrect. By quite a lot in the beginning

[jcoffland]

The time from the WU starting to the first 1% is over a minute.

[muziqaz]

Aaaah, now that makes sense.
What I was looking at is time between printout of 0% and 1%.
I believe that would be the right way to calculate the TPF: start calculating from 0% printout, not when WU is initialising, as that can take sometimes several minutes (10s of minutes) on large GPU projects, and that time is not dependant on GPU performance, but CPU performance.
We basically need pure TPF value. Checkpoints are different matter though

[muziqaz]

Another observation. Have new hardware on Linux, and at 3% TPF is being shown shorter than it is in reality, by like 10s (5m11s instead of real 5m21s). Done page refresh, but no change. However, clicking on the log page in web-control, and back to main page, normalizes TPF to what it should be in main page, but WU history is still showing shorter TPF for some reason.

[muziqaz]

There is new development in this issue:
After PC is woken up from sleep (Win or Linux), WU TPF is being shown either in negative or in milliseconds and PPD is astronomical. I understand this is something to do with sleep function, but the TPF never really normalises.
On top of that, same behaviour is observed when fahclient is being updated. After update, TPF is in milliseconds instead of 10 minutes. Here is a screenshot of WU, which experienced FAHClient update, which caused TPF to misbehave, and then system restart, which killed it. It remains in WU History with overblown PPD values.
I hope if/when client starts evaluating TPF from most recent 3 frames (%s) this will go away.

[muziqaz]

Linux update process doesn't even flinch from remotely monitoring PC perspective. Version number changes in split second, and progress continues as if there was no fahclient restart after update. Logs indicate that FAHClient did restart upon update. So TPF distortion after client update is Windows only, for now.