Closed borzaka closed 6 years ago
@fireice-uk Please don't :)
I try to give as many information I can, and I hope it helps.
Another report after ~28 hours.
RESULT REPORT
Difficulty : 400015
Good results : 2005 / 2068 (97.0 %)
Avg result time : 46.0 sec
Pool-side hashes : 152906698
Top 10 best results found:
| 0 | 414940385 | 1 | 259847514 |
| 2 | 246063839 | 3 | 239841035 |
| 4 | 118868302 | 5 | 91313547 |
| 6 | 81895170 | 7 | 53190579 |
| 8 | 39688135 | 9 | 38225717 |
Error details:
| Count | Error text | Last seen |
| 53 | Job not found. | 2018-03-06 23:13:21 |
| 10 | Invalid nonce; is miner not comp | 2018-03-06 19:27:38 |
(Dev branch compiled on 01.30.)
With ~6600 H/s
@CircusDad It occurs everytime a new block arrives, what your seeing as hard evidence from comment #835 is when an actual share was found, AND got rejected as stale. Don't forget you still lose all that hashing time mining stale block, its just if you did not find a share, it is never reported on the console printout. So you don't have hard evidence from the miner logs. Perhaps don't rely on logs and try using dtrace for your evidence (assuming your on linux).
Tl;Dr; The lost hashing time on a stale block is ONLY logged if an actual stale share is found (which depending on difficulty and hashrate could be every 100-100000 times). So multiply what your seeing by 100-1000000 times.
@fireice-uk
Since (block 11' diff + total_chain_diff) > (block 11 diff + total_chain_diff) chain with block 11' is longer and the rest of the network reorgs accordingly.
Yea.. your stale share just caused an orphan block for some pool somewhere, now its just an asshole move to mine stale shares. Your causing orphan blocks for legit pools that are small and community driven. Also it does not help the network, that stale share could very likely have been the next valid block, had you done the PoW on the new blocktemplate.
I need more popcorn.
Your causing orphan blocks for legit pools that are small and community driven.
:'( I will let you donate your hashrate to a mom&pop pool like nicehash then.
On a more serious note, do you know a saying "Better to remain silent and be thought a fool than speak and remove all doubt."
Sorry, I just can't say it with a straight face, "mom&pop community owned pool". LOL. Thanks for brightening up my evening m8.
I stand corrected. Being reported as a "Job not found" means that the miner found the hash of proper difficulty (share) during that one second and thus had the whole share rejected. Per @borzaka's stats, it probably took him about 46 seconds on average to find that hash and it will probably be another 46 seconds before he finds another.
He only spent 1 second finishing his last assignment but, depending how you do the 'sunk cost' probability math, he lost not 1 second of mining credit but rather ~46 seconds of mining credit (his average share time)
To use @borzaka latest results,
He had 53 "job not found" in 2068 shares at an average share time of 46 seconds.
(53 46 seconds lost credit) / ( 2068 46 mining seconds ) = 2.6% lost mining credit when mining to nicehash
That is a bit more significant then I stated before .
I happen to agree with @fireice-uk that a pool should credit for all assigned work that is performed. But I do think that since we know that nicehash doesn't, perhaps it is worth a "FastJobSwitch" feature that automatically becomes active as part of what it means when "nicehash" is set to true.
IOW, Nicehash blows.
@CircusDad
But I do think that since we know that nicehash doesn't, perhaps it is worth a "FastJobSwitch" feature that automatically becomes active as part of what it means when "nicehash" is set to true.
I would have two objections to that:
My prediction is that nicehash will drop support for Monero anyway, so this whole debate may be moot.
After mining ~16 hours, this is my result:
My config
config.txt:
amd.txt
cpu.txt
Basic information
xmr-stak/2.2.0/c4400d19/master/win/nvidia-amd-cpu/aeon-monero/20