Validate-shares stats does not match the pool's stats

[ismet]

Hello,

I have been using T-Rex Miner with --validate-shares parameter in ethermine pool for 12 hours now.

T-Rex Miner log tells, there are 0 rejected and 20 invalid shares in 9436 shares

However, ethermine statistics says there are 0 rejected but too many stale shares.

I assume T-Rex Miner's I (Invalid/Incorrect) Share is actually Stale Share. Am I wrong? Then, why do the numbers not match? There is even a big difference between them. I wish there were a more detailed explanation about how the validate-shares and "R", "I" stats work.

[trexminer]

Invalid shares don't get sent to the pool, so the pool statistics won't show them. Stale shares aren't reported to the miner (by ethermine at least), so you won't see them in the miner stats. So, essentially, you're comparing apples with oranges :)

R are the shares rejected by the pool, and I are invalid shares discarded by the miner.

[ismet]

Thanks @trexminer, I got it better now.

Then, what would be the benefit of discarding the invalid shares? By doing that, I don't get any rejected share reported by the pool. Is it possible that a pool rejects a share even though the miner sends valid shares?

[trexminer]

Then, what would be the benefit of discarding the invalid shares?

This way you can check how stable your overclock is. If a GPU produces invalid solutions, you may want to dial down your memory clocks.

Is it possible that a pool rejects a share even though the miner sends valid shares?

In theory, it is possible, yes.

[ismet]

What is the maximum invalid share ratio accepted in general?

Let's say we have 2% of invalid solutions on average with higher memory clocks? Could it be more profitable in such case even if there is a loss of 2%? Or, is it more preferred to dial down memory clock speeds as far as it needs, in order to get almost 0% of invalid?

[trexminer]

I recommend asking mining community. My personal opinion is aim for 0% of invalid shares, and I know many people would disagree.

[ismet]

Does validate-shares have any impact on the mining performance? I think the validation intervenes the sending of shares, so it may slow down the whole process.

[dev-archi]

Hi @ismet can I see your config file? I might have the same issue as yours. Thanks in advance!

[WorriedAboutClams]

Does validate-shares have any impact on the mining performance? I think the validation intervenes the sending of shares, so it may slow down the whole process.

I know the T-Rex dev hasn't replied, but I was actually wondering the same thing. After a bit of thinking, I would guess that share validation does not affect mining performance in a practical sense.

The short version: does --validate-shares affect GPU mining speed/hashrate? Not unless you're running several million GPUs on a single CPU. Does --validate-shares affect stale/rejected share rate (by increasing the time it takes to submit shares to your pool)? Almost certainly not, at least not to a realistically measurable extent. Here's my line of thinking:

GPUs are calculating 30-120 million hashes per second. CPUs can run somewhere between a few hundred thousand to a few million hashes (or in our case, validating shares) per second. With --validate-shares enabled, when your GPU finds a share it thinks is right, it sends it to the CPU for the CPU to run that same calculation again to verify the result. Even in the worst case of an old, low-end processor that can only run at 0.1 MH/s (hundreds of times slower than an RTX 3070, around 1/20th of the speed of an i7-7700K) , it is only calculating a single hash. It can probably perform that single hash calculation in less than 10 microseconds. If we assume (very conservatively) that T-Rex is adding an order of magnitude of overhead in order to run those validation commands, the end result is share validation adding significantly under 1 millisecond, somewhere around 1/10 of 1 millisecond, to the time it takes to submit a share to the pool - not the time it takes your GPU to find a share; the time it takes to submit a share once it's been found. The fastest internet latency to connect to a pool (or any server for that matter) is going to be around 10 milliseconds. Share validation, in what I imagine is the absolute worst possible scenario, would add no more than 1% to the latency of submitting a share. And that is extremely conservative. In most real world situations, it's probably adding 0.1% to server/pool latency or less.

And the above is to say nothing about the impact on the actual MH/s or found shares/minute of your GPU. For that, the CPU would have to get "backed up" validating shares in order for the GPU to slow down (or for shares to be rejected as stale because the CPU took too long to validate them). Again, let's say we're running a very old, very slow CPU that can only run at 0.1 MH/s - that's 100,000 hashes per second. For a CPU like that to get backed up, your GPUs would need find more than a hundred thousand shares per second. Not "megahashes per second" - shares per second. To put it realistically, let's say you have the maximum number of RTX 3090s (the highest MH/s individual GPU currently available) running on a mining motherboard - 13 3090s. (Maybe it's 12, they might go higher too, but for the sake of simplicity let's say you have a 13 GPU motherboard.) Going by my current ETH difficulty on NiceHash right now (which is quite a bit lower than most pools, and will therefore be finding quite a bit more shares per second), a 3090 can find about 6 shares per minute, or 0.1 shares per second. Thirteen 3090s would be roughly 1.3 shares per second - 0.00000013% of the validation capacity of that extremely low end CPU we're (hypothetically) running the share validation on.

Looking at it from the other end of "what hashrate would it take for share validation to materially affect your rig's mining hashrate", our goal is 100,000 shares per second to match that hypothetical low-end CPU's 0.1 MH/s speed. To hit that rate, you'd need something like 1,000,000 RTX 3090s running on a single CPU. To put it in perspective, that'd be like 17% of the entire global Ethereum network hashrate.

In other words, even an extremely poorly implemented share validation process in a mining program wouldn't be able to come within 6 orders of magnitude of being the limiting factor in a rig's mining hashrate.

[trexminer]

@WorriedAboutClams I should've mentioned something that would've greatly simplified your calculations: depending on the algorithm, CPU share validation takes about 2-4ms on my Ryzen 5600G. It's a synchronous and single-threaded process, so adding more cores won't help, meaning that all your shares are delayed by 2-4ms before the miner sends them to the pool. So, the effect of enabling share validation is equivalent to increasing your ping time by a few milliseconds.

[WorriedAboutClams]

@trexminer Hahaha welp, that answers that. Thanks for the info!