Thank you for the hint. Before with Cointron, I also had a steady 100% GPU load. But I trying out CPP-Eth now with MHP. I´m from Germany, so I selected their European server.
"GPU gave incorrect result" occurs when GPU hashing result does not match to recheck of CPU hashing. (ethminer recheck hash result with CPU before it submit to pool) So this message even don't come from pool, just caught by your miner program itself.
4. Have tried without these options? --cl-local-work 256 --cl-global-work 16384
europe1 and us-east1 server's pool code is totally same, so it should not be the problem related to europe1 I think.
Additionally, in most cases, --farm-recheck 200 works better than 400. 400 means you recheck new work every 0.4 second, and it would cause you more stale shares.
Not a clear solutions still, but hope we helped you.
1. Ethminer (all public versions afaik) has a bug that causes incorrect invalid GPU result errors when new work arrived the moment before the share was found. Higher cl-work values exagerate this.
--cl-local-work sets m_localWorkSize m_localWorkSize is passed to EthashGPUMiner::configureGPU, which sets s_workgroupSize s_workgroupSize is passed to the cl kernel as GROUP_SIZE in the cl code, HASHES_PER_LOOP is set to (GROUP_SIZE / THREADS_PER_HASH)
1. Ethminer (all public versions afaik) has a bug that causes incorrect invalid GPU result errors when new work arrived the moment before the share was found. Higher cl-work values exagerate this.
It seems like just timing (synchronization) issue of ethminer then. MPH starts from low diff, so @Termie's miner would had to submit many shares at first and it caused such frequent job reset, I think.
Just keep mining, and difficulty will go up, timinig issue will not happen frequently. I hope you try it again.
Now, miningpoolhub is showing daily recent credits on dashboard page.
Thanks.
That's a bit easier than searching the transaction history for payouts, but that's not what I was talking about. Dwarf shows you "Earnings in the last 24 hours"
We distributed some ETH to miners to say "Thank you for mining with us"
Distribution target block height is 1252760 It was mined at 2016-03-31 (UTC) and block amount is 5.032248555229755
If you were mining at that time, you will get double of that reward.
Actually 1252760 block is 700th block mined from miningpoolhub. We just picked one of them looking good.
These are distributed as "Bonus". You can find them by setting type as "Bonus" at Transactions page. This bonus is same as normal "Credit", so you can withdraw them. If you want Bonus to be auto exchanged, just click Transfer arrow at Wallet page.
Can you clarify the actual hashrate? Is it the number directly reported from ethminer which is set on each rig manually?
If you were meaning this, then it's impossible right now. Pool don't gather submitHashrate value reported from ethminer. Maybe we will add the feature later. The reason why we ignore this value is that it is not the real hashrate, and it can be far away from the real value when miner changes its rig configuration time to time.
How about using worker monitor feature? It will alarm your miner when that miner don't input share for certain time.
What do you mean 2%? Our transaction fee is almost same as gas price spent for transfer on ethereum network. And you can adjust the auto payout amount by yourself to lower the ratio of transaction fee. Also you can change donation percent to 0 as well.
Keep in mind that most exchange sites charge deposit fee for ethereum. Transferring to Poloniex, Bittrex would get lower than actual sent amount. You can check that from ethereum blockchain sites too. Don't blame pool for this.
Now, miningpoolhub is showing daily recent credits on dashboard page.
Thanks.
That's a bit easier than searching the transaction history for payouts, but that's not what I was talking about. Dwarf shows you "Earnings in the last 24 hours"
@bitcanuck remember, dwarf keeps fees and uncle inclusion rewards, so that's a decent chunk lost vs MPH which pays everything.
Eth-proxy is also kinda broken for vardiff, so that might be a reason you see more consistent results with genoil.
In theory MPH should pay a bit more, all else being equal. But if eth-proxy is more efficient with dwarf than mph, then that could make dwarf more profitable.
Sorry for late reply. I worked abroad for few days and had connectivity issue time to time.
eth-proxy is originally came from bitcoin mining stratum from slush0 (https://github.com/slush0/stratum-mining-proxy) and not intended for ethereum mining actually. eth-proxy has many lines of unused codes, quite messy, and this is why miners suffer reconnection fail problem. (When eth-proxy lost connection, it doesn't recover occasionally)
It was better than ethminer's original polling getWork, but it's quite inefficient because every local ethminer is polling getWork still. farm-recheck 200ms option means ethminer will retry polling every 0.2 seconds. So, in average, ethminer would get new work about 100ms slower than eth-proxy detects. This delay may look small, but this amount of delay is like "other region's server request delay". (US Miners connecting to Europe server like delay)
If miner reduces, farm-recheck value to 100ms, it would harm the overall performance. ethminer makes http request to getWork every 0.1s, and this massive amount of local request can harm eth-proxy. Or if you connect many ethminer to eth-proxy, then eth-proxy will suffer from bad performance as well. eth-proxy is better than ethminer's getWork polling, but worse than stratum.
I would like to recommend ethminer-genoil's stratum than eth-proxy if you want real optimized environment.
Sorry for late reply. I worked abroad for few days and had connectivity issue time to time, couldn't answer this question.
We use - dynamic pplns to boost last block shares (not pure block average pplns) - last 5 block average shares to 70% - last block shares to 30% - reverse payout from archive disabled.
I understand that it's not fair, so we enabled "reverse payout from archive", and increased last block count number from 5 to 7. "Reverse payout from archive" is quite complex to describe because it works differently at certain conditions. This option prevents some bad pool hoppers getting reward but has bad effects on really short block time. So, we enabled this option and increased last block count to punish bad pool hoppers but reward good miners.
We traversed this kind of distribution and found two blocks. 1250126, 1331438 both blocks were having similar issue. We will distribute these block reward again from our pocket. Total 10 ETH Bonus reward will be distributed to each users according to nearest block contribution.
Sorry about this distribution. These are not whole miscalculation, only 2 blocks out of 2120 total mined blocks which encountered some rarely happening conditions.
This kind of unfair distribution would not happen again. Thanks.
After running genoil's ethminer for a few days, I'm getting earings perfectly in line with the calculators. Although ethminer reports ~21mh/s for a single R9 380, the mph dashboard reports ~23. I suspect that is because of the grossing-up that mph does, which I would recommend they stop doing as it is deceiving people into thinking they are getting better hashrates with the pool than they really are.
I've done a build of genoil's ethminer for ubuntu 14.0.4 and plan to install it on my linux mining rig sometime this weekend.
@bitcanuck Seems like genoil's ethminer would be the major miner soon. Actually we are going to release all-in-one-miner package for auto switching various algo and genoil-ethminer will be used for main etherereum (ethash) miner. Happy to hear this precious info. Thank you.
Did you guys change anything lately? Horrible luck yesterday and today. Made like -25% less than average.
Normally there are 120 blocks found each day but now its like 90 and the hashrate is still high.
@adaseb Well, we didn't change some big things that would impact the mining luck lately. Latest major change was PPLNS distribution settings from other server. Block finding luck is getting better slowly, Mined 103 blocks for last 24 hours.
120 block finding was quite lucky considering the net difficulty these days. As we check block finding stats very frequently, we already noticed the block luck changes. It is on the normal behaviour area.
Regarding the multi-algo miner, I doubt it will be worth doing as nothing has stayed more profitable than eth mining. Unless another coin is at least 20% more profitable than eth for more than 20 days, I wouldn't bother to try mining it.
Thanks for detailed research about optimizing GPU.
Multi-algo switching is currently experimental state for ethereum but it would get more coins in theory. Here's a nice captured state. Not usual but happens time to time.
Since coin switching is so easy and done automatically, you can mine temporarily low difficulty stated coins and come back to ethereum within few minutes. You can see that Ethereum is on the fourth row, Normalized Profit at 6.40754 Digibyte-Skein is at 8.59067 which is 34% more profitable. Digibyte-Skein does not stay long at that profitable level though, but it has some positive effects.
(1) You can mine the most profitable coin in realtime. It's Digibyte in this case. (2) Your hash moving to other coin decreases total hashrate of ethereum. (3) You make buy order at ethereum on exchange sites and it makes ethereum price up.
You get more ethereum than just mining ethereum continually, lowers ethereum hashrate a bit, push up ethereum price a bit. So it helps ethereum mining environment healthy. When there's many miners on this auto switching, this bit of difference can be significant someday.
I would like to recommend ethminer-genoil's stratum than eth-proxy if you want real optimized environment.
I decided to do more investigating as to why I was getting better mining returns with genoil's miner. I tried the standard ethminer + eth-proxy with nanopool, and was still getting low returns. But what I noticed was that nanopool was reporting a lot of rejected shares; around 10%. Since mph accepts bad shares but just doesn't give you credit for them, I was unable to see this problem on mph. I had been using global-work 32768 (no local-work), so I switched that to 16384. I also reduced farm-recheck to 100ms from 200ms. With those changes my rejects at nano dropped to under 1%. The smaller global-work gives about 3-4% lower reported hashrate though.
If mph reported rejected shares, I probably would've found this problem over a week ago.
I understand this situation but there's pros and cons on rejected shares reporting.
As many miners on ethereum uses proxy, share reject makes proxy hiccup. Proxy programs try to resend it again, makes inefficient overhead. When something bad happens (maybe bug), proxy programs resend, resend, and resend. That's why you would get very high rejected share rate sometimes. It is the main reason why mph report stale share as accepted. Stale share treat is quite complex because this can be a hole of pool DDoS attack too.
Even MPH pretends shares accepted to miners, your hashrate speed should be lower than expected when massive stale shares are happening. I'd like to suggest you to check your hashrate changes on "Graphs" page to detect mining optimization problems. Sometimes, miners undervolt their gpu too much or tweak variable, and get better hashrate than before and think that undervolt/tweak worked well. But, some variable tweak can affect the delay of work reset bottleneck, which would cause bad effect on average. So "Graphs" page would be better to measure tweak sometimes.
I also read from some other forum that 100ms would harm the performance. (It was at dwarfpool's eth-proxy bitcointalk as I recall. Well it depends how many rigs are connected to local eth-proxy)
genoil-ethminer's farm-recheck is 0ms in theory because it receive new block immediately by itself. This is why we prefer genoil-ethminer than eth-proxy.
We would consider improving stale share report things. Maybe we would report to miners "accepted" but show real statistics on webpage.
I also read from some other forum that 100ms would harm the performance. (It was at dwarfpool's eth-proxy bitcointalk as I recall. Well it depends how many rigs are connected to local eth-proxy)
But it seems you didn't actually test it yourself. On a dual-core celeron CPU, ethminer 1.2.2 consumes
Share does not seem to be accepted. Somethings wrong.
Did you log your ethminer mining? It would be helpful if you send me log file. And what is the ethminer's version?
Seems like connectivity issue or miner program bug but not sure at this moment. us-east1 server went down 2016-04-20 04:19 UTC to 04:50 (about 30 minutes) but I don't think it affected whole error. ethminer-genoil seems like failed to reset connectivity issue. I'm curious that why it didn't come back even after you restart.
I would credit some eth to you appropriate amount. How much do I have to credit to your account? based on expected earnings of that period of time
Comments
"GPU gave incorrect result" occurs when GPU hashing result does not match to recheck of CPU hashing.
(ethminer recheck hash result with CPU before it submit to pool)
So this message even don't come from pool, just caught by your miner program itself.
Here's the source code.
https://github.com/ethereum/libethereum/blob/d5026dc347419ab0cdc2b105a34ae57022fb2b33/ethminer/MinerAux.h#L574
I have no idea why it happens when changing pool.
Pool just give data to solve and receive solutions, and bottleneck happens on your ethminer recheck.
1. Reading the below link from google, it seems like OC problem.
https://www.reddit.com/r/ethereum/comments/3i9jmv/failure_gpu_gave_incorrect_result/
2. Maybe delete DAG and regenerating it would solve it.
3. Try genoil's ethminer. https://github.com/Genoil/cpp-ethereum/tree/master/releases
This ethminer fork has fixed many bugs, compatibility issues.
4. Have tried without these options?
--cl-local-work 256 --cl-global-work 16384
europe1 and us-east1 server's pool code is totally same, so it should not be the problem related to europe1 I think.
Additionally, in most cases, --farm-recheck 200 works better than 400. 400 means you recheck new work every 0.4 second, and it would cause you more stale shares.
Not a clear solutions still, but hope we helped you.
--cl-local-work sets m_localWorkSize
m_localWorkSize is passed to EthashGPUMiner::configureGPU, which sets s_workgroupSize
s_workgroupSize is passed to the cl kernel as GROUP_SIZE
in the cl code, HASHES_PER_LOOP is set to (GROUP_SIZE / THREADS_PER_HASH)
It's definitely not ignored.
@Termie
It seems like just timing (synchronization) issue of ethminer then.
MPH starts from low diff, so @Termie's miner would had to submit many shares at first and it caused such frequent job reset, I think.
Just keep mining, and difficulty will go up, timinig issue will not happen frequently.
I hope you try it again.
Now, miningpoolhub is showing daily recent credits on dashboard page.
Thanks.
OK. We will make it.
Sorry
We distributed some ETH to miners
to say "Thank you for mining with us"
Distribution target block height is 1252760
It was mined at 2016-03-31 (UTC)
and block amount is 5.032248555229755
If you were mining at that time, you will get double of that reward.
Actually 1252760 block is 700th block mined from miningpoolhub. We just picked one of them looking good.
These are distributed as "Bonus". You can find them by setting type as "Bonus" at Transactions page.
This bonus is same as normal "Credit", so you can withdraw them.
If you want Bonus to be auto exchanged, just click Transfer arrow at Wallet page.
Thanks.
One of my rigs sometimes mine with 4 out of 5 gpus and I need to restart ethminer to get the full speed.
Can you clarify the actual hashrate?
Is it the number directly reported from ethminer which is set on each rig manually?
If you were meaning this, then it's impossible right now. Pool don't gather submitHashrate value reported from ethminer. Maybe we will add the feature later. The reason why we ignore this value is that it is not the real hashrate, and it can be far away from the real value when miner changes its rig configuration time to time.
How about using worker monitor feature? It will alarm your miner when that miner don't input share for certain time.
What do you mean 2%?
Our transaction fee is almost same as gas price spent for transfer on ethereum network.
And you can adjust the auto payout amount by yourself to lower the ratio of transaction fee.
Also you can change donation percent to 0 as well.
Keep in mind that most exchange sites charge deposit fee for ethereum.
Transferring to Poloniex, Bittrex would get lower than actual sent amount. You can check that from
ethereum blockchain sites too.
Don't blame pool for this.
We are absolutely 0.9% fee, no hidden fees.
Now, mph dashboard is showing last 24 hours earnings.
Hope you like it.
Thanks.
Now we show worker list sorted by its name.
Just little improvement, hope all miners like it.
Eth-proxy is also kinda broken for vardiff, so that might be a reason you see more consistent results with genoil.
1331481 Confirmed anonymous 13/04 22:16:14 (UTC) 26,766,391,334,447.00 5.000000 1,772,668 861,713 1,206,299 68.05
1331438 Confirmed anonymous 13/04 22:05:11 (UTC) 26,845,115,512,709.00 5.000000 1,777,882 20,128 41 0.00
1331436 Confirmed anonymous 13/04 22:04:56 (UTC) 26,832,013,939,306.00 3.750000 1,777,014 854,380 135,612 7.63
Sorry for late reply.
I worked abroad for few days and had connectivity issue time to time.
eth-proxy is originally came from bitcoin mining stratum from slush0 (https://github.com/slush0/stratum-mining-proxy) and not intended for ethereum mining actually. eth-proxy has many lines of unused codes, quite messy, and this is why miners suffer reconnection fail problem. (When eth-proxy lost connection, it doesn't recover occasionally)
It was better than ethminer's original polling getWork, but it's quite inefficient because every local ethminer is polling getWork still. farm-recheck 200ms option means ethminer will retry polling every 0.2 seconds. So, in average, ethminer would get new work about 100ms slower than eth-proxy detects.
This delay may look small, but this amount of delay is like "other region's server request delay". (US Miners connecting to Europe server like delay)
If miner reduces, farm-recheck value to 100ms, it would harm the overall performance. ethminer makes http request to getWork every 0.1s, and this massive amount of local request can harm eth-proxy. Or if you connect many ethminer to eth-proxy, then eth-proxy will suffer from bad performance as well. eth-proxy is better than ethminer's getWork polling, but worse than stratum.
I would like to recommend ethminer-genoil's stratum than eth-proxy if you want real optimized environment.
Sorry for late reply.
I worked abroad for few days and had connectivity issue time to time, couldn't answer this question.
We use
- dynamic pplns to boost last block shares (not pure block average pplns)
- last 5 block average shares to 70%
- last block shares to 30%
- reverse payout from archive disabled.
Below link is blocks page.
https://ethereum.miningpoolhub.com/index.php?page=statistics&action=blocks&height=1331438&prev=1
1331438 was found at 0.00% shares, it only took 41 actual shares while other block's shares are much bigger. Pool was giving whole reward to one miner.
I understand that it's not fair, so we enabled "reverse payout from archive", and increased last block count number from 5 to 7.
"Reverse payout from archive" is quite complex to describe because it works differently at certain conditions. This option prevents some bad pool hoppers getting reward but has bad effects on really short block time.
So, we enabled this option and increased last block count to punish bad pool hoppers but reward good miners.
We traversed this kind of distribution and found two blocks.
1250126, 1331438 both blocks were having similar issue.
We will distribute these block reward again from our pocket. Total 10 ETH Bonus reward will be distributed to each users according to nearest block contribution.
Sorry about this distribution. These are not whole miscalculation, only 2 blocks out of 2120 total mined blocks which encountered some rarely happening conditions.
This kind of unfair distribution would not happen again.
Thanks.
Normally there are 120 blocks found each day but now its like 90 and the hashrate is still high.
If you don't use farm-recheck, you are not maximizing potential of ethminer. farm-recheck 200 is better than not using it.
@bitcanuck
Seems like genoil's ethminer would be the major miner soon.
Actually we are going to release all-in-one-miner package for auto switching various algo and genoil-ethminer will be used for main etherereum (ethash) miner. Happy to hear this precious info. Thank you.
Well, we didn't change some big things that would impact the mining luck lately. Latest major change was PPLNS distribution settings from other server. Block finding luck is getting better slowly, Mined 103 blocks for last 24 hours.
120 block finding was quite lucky considering the net difficulty these days. As we check block finding stats very frequently, we already noticed the block luck changes. It is on the normal behaviour area.
Hope we find more blocks soon.
Thanks.
Thanks for detailed research about optimizing GPU.
Multi-algo switching is currently experimental state for ethereum but it would get more coins in theory.
Here's a nice captured state. Not usual but happens time to time.
Since coin switching is so easy and done automatically, you can mine temporarily low difficulty stated coins and come back to ethereum within few minutes.
You can see that Ethereum is on the fourth row, Normalized Profit at 6.40754
Digibyte-Skein is at 8.59067 which is 34% more profitable.
Digibyte-Skein does not stay long at that profitable level though, but it has some positive effects.
(1) You can mine the most profitable coin in realtime. It's Digibyte in this case.
(2) Your hash moving to other coin decreases total hashrate of ethereum.
(3) You make buy order at ethereum on exchange sites and it makes ethereum price up.
You get more ethereum than just mining ethereum continually, lowers ethereum hashrate a bit, push up ethereum price a bit. So it helps ethereum mining environment healthy.
When there's many miners on this auto switching, this bit of difference can be significant someday.
Yesterday I made -18% less compared to F2Pool, previous day was -11%, and day before was -25%.
Its costing me too much money staying on this pool.
I understand your decision.
I feel sorry that you got less from miningpoolhub. I tried my best but can't make a block reward from my own.
F2Pool's PPS seems quite stable. Please try our pool when f2pool's reward gets lower or auto switching is needed.
Thank you for all your feedback and support.
I understand this situation but there's pros and cons on rejected shares reporting.
As many miners on ethereum uses proxy, share reject makes proxy hiccup. Proxy programs try to resend it again, makes inefficient overhead. When something bad happens (maybe bug), proxy programs resend, resend, and resend. That's why you would get very high rejected share rate sometimes. It is the main reason why mph report stale share as accepted.
Stale share treat is quite complex because this can be a hole of pool DDoS attack too.
Even MPH pretends shares accepted to miners, your hashrate speed should be lower than expected when massive stale shares are happening. I'd like to suggest you to check your hashrate changes on "Graphs" page to detect mining optimization problems.
Sometimes, miners undervolt their gpu too much or tweak variable, and get better hashrate than before and think that undervolt/tweak worked well. But, some variable tweak can affect the delay of work reset bottleneck, which would cause bad effect on average. So "Graphs" page would be better to measure tweak sometimes.
I also read from some other forum that 100ms would harm the performance. (It was at dwarfpool's eth-proxy bitcointalk as I recall. Well it depends how many rigs are connected to local eth-proxy)
genoil-ethminer's farm-recheck is 0ms in theory because it receive new block immediately by itself. This is why we prefer genoil-ethminer than eth-proxy.
We would consider improving stale share report things. Maybe we would report to miners "accepted" but show real statistics on webpage.
Thanks.
Yeah I didn't test performance farm-recheck value. Just saw the performance related post from bitcointalk.
Share does not seem to be accepted. Somethings wrong.
Did you log your ethminer mining? It would be helpful if you send me log file. And what is the ethminer's version?
Seems like connectivity issue or miner program bug but not sure at this moment.
us-east1 server went down
2016-04-20 04:19 UTC to 04:50 (about 30 minutes) but I don't think it affected whole error. ethminer-genoil seems like failed to reset connectivity issue. I'm curious that why it didn't come back even after you restart.
I would credit some eth to you appropriate amount. How much do I have to credit to your account? based on expected earnings of that period of time