The block reward distribution takes all shares you have over the last 24h into consideration, so as long as that number remains the same you get the same rewards.
A share is also referred to as points in chia, and its just the diff at the time of a partial. If you sum them up over some time frame you get shares per x (or points per x)
So if you have diff 100 and submit 100 partials, that would be 100x100 = 10,000 shares
if you had a diff of 400 and submit 25 partials, that would be 400x25 = 10,000 shares
The higher your diff the higher is the variance of getting a partial, so sometimes it would be more or less then 10,000 shares per day (in the example above). Using a lower diff ensures a better consistency.
I’d recommend using auto diff, and once you reach the limit, setting the diff so that you still get on avg 1 partial per hour, to ensure that even with big luck swings you have some partials every day. That might mean that you wont reach diff 20k or even 100k, depending on your farm size.
Cool. Thank you for clearing it up!! That 24h for calculating the no. of shares for payment is the key then.
Also, the consistency you mention mostly reflects a short timeline, as we can assume that with a longer timeline the chances of having a bad luck will be roughly the same as good one.
Both affect the GPU usage, having a lower diff will result in higher GPU usage, but the plot filter halving will also double the GPU usage as more plots pass the filter for lookups
Yes, the plot filter drop is understood. Also, the diff level setting for c3X plots.
If you could bear with me for a bit longer. Assuming that the harvester will find 100 eligible plots with diff level 200 and will find 10 partials (all plots are c1X). Based on what you wrote before (weighted partials), if we bump diff level to 400, the number of eligible plots will still be at 100, just the number of proofs should drop to 5.
If that is correct, is the GPU power saving coming from the lower number of proofs found (still having the same eligible plots power bias)? Or differently, whether the compute cost of an eligible plot with a proof is slightly higher than without a proof.
if we bump diff level to 400, the number of eligible plots will still be at 100, just the number of proofs should drop to 5.
correct
If that is correct, is the GPU power saving coming from the lower number of proofs found (still having the same eligible plots power bias)? Or differently, whether the compute cost of an eligible plot with a proof is slightly higher than without a proof.
It doesn’t really matter, even if you only get a partial every couple of days, you are not losing anything. Just your payouts will be more random.
That’s one reason, but the other reason is that higher diff will also reduce the compute for lookups themselves, we already saw that with C19 / C20. Just now it’s even more extreme, for a reason, because it allows to compress plots more.
Thank you Max for the extra info. I am still on c19 plots. I have already bumped up my diff to 3x and see that GPU is using less cycles. I will let it run for a day or so and try to double it at that time.
Not really, I was farming 5883 c19 plots since I think last October. I fixed my diff at 120. My pool EC would fluctuate up and down, one day 541 another well over 600, basically the 24 hour figure was often wrong. Change the view to 7 days and it was much closer, over 30 days the average EC was pretty much spot on, so my pool payments would also average out.
My question was not really about the fluctuation, but rather whether the pool is “dropping” some shares if they are too sparse. The answer from Felix suggested that all is fine, as long as the harvester is present once per day. Max further clarified that if done right by the pool, it should not matter at all.
So, we are on the same page as far as using longer time spans for reacting to fluctuation. However, my feeling is that for compressions c19+ (per what Max stated), the diff should not be calculated as it is right now, as it prefers payment smoothness vs. GPU power consumption. Or maybe, it would be nice to have that diff setting have more options (smoothness vs. power efficiency).
