Another day of profitability: September 17

I originally started at h=10 and worked backwards to h=3, then optimized at 5. That provided the lowest loss of hash rate.

excelerator wrote:I originally started at h=10 and worked backwards to h=3, then optimized at 5. That provided the lowest loss of hash rate.

You could also try h=100 for one miner, and then compare that one with all the others. It may result in higher hashrate, but could cost money.

That could result in a work restart penalty. As you pointed out, you still earn more mining at this pool with lower hashrate because the system computes that the loss of hashrate is offset by the increase in profitability. If you set h= too high, then you would override the system's efforts at eeking out profitability and increase your hashrate at the expense of profitability. In the worst case, you would only be assigned to litecoins.

If you try this, let me know what happens, because it might help with optimization of the server. If you don't see any difference, return the h= value to the previous setting.

I set them all to h=100 and I'll let it run.

You can monitor it and let me know what you see.

BTW - I haven't noticed an increase in the hashrate with the increase to 100. Can you confirm that the variable is actually set on your side?

excelerator wrote:I set them all to h=100 and I'll let it run.

You can monitor it and let me know what you see.

BTW - I haven't noticed an increase in the hashrate with the increase to 100. Can you confirm that the variable is actually set on your side?

Yes, but it wasn't effective.

I suggest changing them back, because you're just hurting your profitability since there is no increase in hashrate. I think that h=5 is probably the maximum for most people that makes sense.