Setting the time to request new work

[aetch]

Just now the client is set with a default to request new work at 99% complete, I believe this can be adjusted to be somewhere is the region of 90-100%.

I receive a range of work units which produce a wide variability in the tpf ranging from mere seconds (sub 30s) to several minutes (currently my GPU is just under 2 minutes and CPU just over 4 minutes)

I'm also aware that the time to download work units varies greatly and can vary from under 10 seconds to several minutes due to the size of the payload and network traffic conditions (my latest GPU WU took 4 minutes to download).

It has bothered me for some time that the time to trigger the request for the next work unit is based on the percentage progress of the current work unit.

Is there a mechanism/setting available which triggers the next request based upon a time based ETA. I would like to set the trigger to something like 1-2 minutes, so it occurs relatively earlier with short units and later with big units.

[bruce]

I understand your concern. I've had similar thoughts.

The one thing supporting the % concept is that it's a definite number. There's always a 99%. Personally, I like 100%. That gives brief interval during which the WU that was just completed can compress the results. In fact, over a number of WUs it doesn't make a major impact on PPD.

Unlike the % complete, the ETA isn't a very reliable number since the client has to extrapolate from recent measurements and the variability in download speed isn't particularly rewarding, either.

You're welcome to make a formal enhancement request on githhub if you can convince yourself that a particular choice would actually meet with widespread agreement as being an improvement.

[iero]

Given that electronics apart from high operating temperatures also dislike developing Deltas in temperatures during operation, one could argue that having the next WU ready to go before the current one ends, would allow the GPU to remain at a constant temp and thus prolong its lifespan.
Personally, instead of a mandated standard checkpoint, say 99% as it stands now, there should be a command to manually set it even earlier. If the system runs 24/7 a checkpoint at 80~85% would allow for continuous and uninterrupted operation of the GPU.

[Joe_H]

Personally, instead of a mandated standard checkpoint, say 99% as it stands now, there should be a command to manually set it even earlier.

As mentioned in the OP, the range can already be set from 90-100%. 99% is the default.

[bruce]

There's always a significant pause in GPU load while the just-completed WU gets prepared to upload (zipped/tared and erased) before FAHClient enqueues that result for uploading. I've never monitored how much temperature shock that produces.

[ajm]

There's always a significant pause in GPU load while the just-completed WU gets prepared to upload (zipped/tared and erased) before FAHClient enqueues that result for uploading. I've never monitored how much temperature shock that produces.

I took a look on a few cards: 2080ti and 2080S on water: delta ~15-18°C (max. 30-48)
2070S air-cooled: 14°C (58-72).
Doesn't look like that big a stress.

[iero]

15°C is indeed a big delta.

[aetch]

Apologies Bruce.

Once I took another look at my logs I found that in a lot of cases, but not all, the next work unit could be downloaded within the time it takes to save and package up the one it's just finished.
Even if 10% of downloads are slow I'm probably losing less than I would from having the next unit sitting several minutes before it can be started.
I have now set my next-unit-percentage to 100%, I'll see how that goes.

[bruce]

Back in the days when data was transferred by modem, we had a lot of 56kbit connections and even though most WUs were smaller, it did take longer to download so 99% was a reasonable number. With modern broadband connections, the time from 100% until the previous WU is ready to transmit is about right.

In the olden days, some people had even slower modems ... and people complained if the next WU ever had to wait, so longer settings were permitted.

[gunnarre]

15°C is indeed a big delta.

What are you basing this on? That is a sort of delta that you can expect from normal gaming use, right?

[iero]

15°C is indeed a big delta.

What are you basing this on? That is a sort of delta that you can expect from normal gaming use, right?

No, it certainly is not. Any delta above 10~12°C on a CPU and a GPU [ say hottest and coldest core on a CPU/ GPU temp and Junction Temp] should lead one to recheck mounting pressure etc. 15°C is a thermal shock, but to be realistic, especially for older cards that take a while to complete WUs, the drops in temperature do not happen often enough to really affect the hardware. In an ideal world it would never happen.

[gunnarre]

Oh, an instantaneous 15°C delta between the coldest and warmest core on a single silicon die would be pretty high, but I think we're talking about cycling between idle and loaded here, not the temperature difference between the cores at the same time.

[ajm]

And it is not instantaneous. According to Afterburner, the highest delta in one second is about 5°C (on a water-cooled 2080ti).

[aetch]

Well, one week in with the next-unit-percentage set to 100% and I look to have increased from 2.4-2.6 million PPD to 2.7-2.8 million PPD.
A tiny little bit less science gets done because of the occasional large payload that takes 4 minutes to download and is now starting at least 30 seconds later, but where do you draw the line.