I too have a ridiculous amount of rejects and HW when mining here. I jumped over to wemineall for about 24 hrs and my rejects went down to <2% with no HW. I really like Nicehash, but this isn't sustainable for me.
Here is what I typically see:
https://bitcointalksearch.org/topic/m.6384125
Btw, I'm using Hashra mini Controlla. Two rpi with 10 gridseeds each. Does anyone else have similar issues, or am I alone? I'm in central USA.
Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 329. (Read 794443 times)
April 27, 2014, 10:28:37 PM
April 27, 2014, 04:58:17 PM
Where are you from? NiceHash has 0.5 second window to treat stale shares as valid after new work is provided. But if you live far away (like Australia or Asia), then I believe you will get high reject rate yes.
I'm in US west coast.
April 27, 2014, 04:45:42 PM
Where are you from? NiceHash has 0.5 second window to treat stale shares as valid after new work is provided. But if you live far away (like Australia or Asia), then I believe you will get high reject rate yes.
April 27, 2014, 04:41:33 PM
Some improvements were applied, most noticeable one is: Fair way for paying providers. It does not matter the order your miners work on, your miners are paid average sum, according to how much work (shares) was provided by them each minute.
A welcomed improvement. Now if only something can be done about those pesty rejects. In particular I notice that rejects come in batches and streaks. For example, if the next submitted share is rejected then the probability is high that the next several consecutive shares will also get rejected. It's almost like there's a new block or new work but the server didn't notify the miner in time. This causes higher than desirable reject rates when compared to your classic multipool.
April 27, 2014, 03:31:05 PM
Your p= is now checked against "Currently paying", which you can see on the main page.
To all providers on NiceHash. Please, test out new sgminer with added functionalities that makes your mining on NiceHash faster and with less bugs.
Source & linux: https://github.com/bitbandi/sgminer
Windows 32-bit binaries: https://www.dropbox.com/s/mzq7ia595o785ey/sgminer-win32.zip
To all providers on NiceHash. Please, test out new sgminer with added functionalities that makes your mining on NiceHash faster and with less bugs.
Source & linux: https://github.com/bitbandi/sgminer
Windows 32-bit binaries: https://www.dropbox.com/s/mzq7ia595o785ey/sgminer-win32.zip
April 27, 2014, 03:09:33 PM
Some improvements were applied, most noticeable one is: Fair way for paying providers. It does not matter the order your miners work on, your miners are paid average sum, according to how much work (shares) was provided by them each minute.
I'm glad to see this implemented, but how does this affect the p=xxx minimum? Will you drop me if the job I'm mining is below the minimum or if the average payout is below minimum? April 27, 2014, 01:44:46 PM
If you have Windows based miner, you can check Windows build: https://www.dropbox.com/s/mzq7ia595o785ey/sgminer-win32.zip
April 27, 2014, 12:58:02 PM
Quick info: we've updated beta version of sgminer that adds extranonce1 feature when switching orders, you are welcome to test it and please report any issues to nicehashdev: https://github.com/bitbandi/sgminer/. Thanks for help!
April 27, 2014, 12:31:43 PM
Short info for buyers: we've improved compatibility with many popular pools (such as ipominer.com, manicminer.in, chunkypools.com, miningpoolhub.com, etc.) therefore all orders using the most popular pools should work flawlessly. If you do have some issues with some specific pool, please do not hesitate to let me know about the issues via PM. Thanks!
April 27, 2014, 12:21:38 PM
Does the crash happen ever if you don't have this pool as backup pool?
No, the crash does not happen.
April 27, 2014, 11:50:43 AM
Does the crash happen ever if you don't have this pool as backup pool?
April 27, 2014, 11:36:31 AM
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
First of all, thank you for the fixes.
The "no more reconnects when switching orders" fix seems to work for me (I can see several "PoolName extranonce change requested" in sgminer).
But when I use a specific pool, sgminer immediatly returns to the shell (on Linux). It works with this pool when I use the "--no-extranonce-subscribe" option.
The pool return the following response when it receives an unknown command (the mining.extranonce.subscribe one): {"error": "Unrecognized request provided", "id": 0, "result": false}. I think the "error" parameter value is not a valid JSON-RPC format. Maybe it's the cause of the crash of sgminer.
For the idle bug, I do not use the p=xxx parameter so I can't say.
Hello, can you share with us the name of the pool that reports incorrect msg back, so we can perform tests against it. Does crash happen when your miner tries to connect/subscribe/auth to it?
Just sent you a PM with the pool name.
The crash happens just after the startup of sgminer. The offending pool is one of my backup pool, but sgminer seems to check if the pool is Alive at startup. The crash happens just after the response to the mining.extranonce.subscribe request from this pool. (here after is the response {"error": "Unrecognized request provided", "id": 0, "result": false}). If I remove the pool from the backup, sgminer works fine.
April 27, 2014, 11:18:15 AM
Another improvement now after we introduced fair payments for providers: Minimal limited hashpower is now 0.05 GH/s -> 50 MH/s.
April 27, 2014, 11:01:20 AM
Some improvements were applied, most noticeable one is: Fair way for paying providers. It does not matter the order your miners work on, your miners are paid average sum, according to how much work (shares) was provided by them each minute.
April 27, 2014, 06:38:49 AM
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
First of all, thank you for the fixes.
The "no more reconnects when switching orders" fix seems to work for me (I can see several "PoolName extranonce change requested" in sgminer).
But when I use a specific pool, sgminer immediatly returns to the shell (on Linux). It works with this pool when I use the "--no-extranonce-subscribe" option.
The pool return the following response when it receives an unknown command (the mining.extranonce.subscribe one): {"error": "Unrecognized request provided", "id": 0, "result": false}. I think the "error" parameter value is not a valid JSON-RPC format. Maybe it's the cause of the crash of sgminer.
For the idle bug, I do not use the p=xxx parameter so I can't say.
Hello, can you share with us the name of the pool that reports incorrect msg back, so we can perform tests against it. Does crash happen when your miner tries to connect/subscribe/auth to it?
April 26, 2014, 11:38:44 PM
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
I tried your fixed version, and after ~8 hours it started acting up.
Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while.
I don't think the idle bug is fixed.
If you're using the bitbandi/sgminer code, then the included fix is a bit different - https://github.com/bitbandi/sgminer/commit/77545de0e8b0d0a6e57cf518920de5e6b818e290 . You won't want to be using pool->idle = true; AND this commit. Closing the stratum connection like in that commit causes pool->stratum_active = pool->stratum_notify = false (but does not affect pool->idle). I can't say if this works, as I haven't tested it myself. But, from my read thru of the code, the program flow will be quite different then my patch, and I was marking the pool idle instead of suspending stratum for a reason.
Ah, alright. Well that was my poor judgement just blindly adding in the pool->idle = true; in addition to the suspending pool thing.
I'll try to debug the issue further if it occurs again - the issue is that it takes so damn long to trigger
That is because neither phzi nor ebandi implemented a proper idle bug fix. They addressed the symptom but not the cause. Also, ebandi is missing an important piece of a fully backwards compatible extranonce subscription implementation. Currently, it is unstable universally (i.e. works fine at nicehash but will break unexpectedly at other pools). I know why that is happening too, but keep working on it though. You'll get there eventually.
April 26, 2014, 08:23:33 PM
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
I tried your fixed version, and after ~8 hours it started acting up.
Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while.
I don't think the idle bug is fixed.
If you're using the bitbandi/sgminer code, then the included fix is a bit different - https://github.com/bitbandi/sgminer/commit/77545de0e8b0d0a6e57cf518920de5e6b818e290 . You won't want to be using pool->idle = true; AND this commit. Closing the stratum connection like in that commit causes pool->stratum_active = pool->stratum_notify = false (but does not affect pool->idle). I can't say if this works, as I haven't tested it myself. But, from my read thru of the code, the program flow will be quite different then my patch, and I was marking the pool idle instead of suspending stratum for a reason.
Ah, alright. Well that was my poor judgement just blindly adding in the pool->idle = true; in addition to the suspending pool thing.
I'll try to debug the issue further if it occurs again - the issue is that it takes so damn long to trigger
April 26, 2014, 08:00:58 PM
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
I tried your fixed version, and after ~8 hours it started acting up.
Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while.
I don't think the idle bug is fixed.
If you're using the bitbandi/sgminer code, then the included fix is a bit different - https://github.com/bitbandi/sgminer/commit/77545de0e8b0d0a6e57cf518920de5e6b818e290 . You won't want to be using pool->idle = true; AND this commit. Closing the stratum connection like in that commit causes pool->stratum_active = pool->stratum_notify = false (but does not affect pool->idle). I can't say if this works, as I haven't tested it myself. But, from my read thru of the code, the program flow will be quite different then my patch, and I was marking the pool idle instead of suspending stratum for a reason.
April 26, 2014, 07:46:25 PM
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
I tried your fixed version, and after ~8 hours it started acting up.
Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while.
I don't think the idle bug is fixed.
April 26, 2014, 02:41:57 PM
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
It contains two fixes:
- idlebug fix
- support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
First of all, thank you for the fixes.
The "no more reconnects when switching orders" fix seems to work for me (I can see several "PoolName extranonce change requested" in sgminer).
But when I use a specific pool, sgminer immediatly returns to the shell (on Linux). It works with this pool when I use the "--no-extranonce-subscribe" option.
The pool return the following response when it receives an unknown command (the mining.extranonce.subscribe one): {"error": "Unrecognized request provided", "id": 0, "result": false}. I think the "error" parameter value is not a valid JSON-RPC format. Maybe it's the cause of the crash of sgminer.
For the idle bug, I do not use the p=xxx parameter so I can't say.
Jump to: