Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 328. (Read 794394 times)
April 30, 2014, 12:21:25 AM
please Add X11
April 29, 2014, 06:00:37 PM
After having a look at your site and not finding anything, I decided to ask you here: do you have an affiliate program (for referring people who are buying hashing power)?
April 29, 2014, 02:34:55 PM
+2
As a GPU-only miner with power costs the most profitable coins are x11 (dark,hiro,etc.) right now.
April 29, 2014, 10:30:16 AM
April 29, 2014, 12:26:21 AM
nicehashdev, Hi. When add X11 ? 
April 28, 2014, 08:32:40 PM
Under DDOS attack.
April 28, 2014, 08:04:54 PM
That is nothing else but stale share what you are showing. We have upped share validity to 700ms now. Stale shares will be lower.
April 28, 2014, 06:45:31 PM
Are you talking about rejects or HW errors. Let's not make this the same thing.
You have two types of rejects; stale share and share below target. First one happens when you are too late to the party (basically, too high ping from you to the pool), second one happens due to incorrect configurations, wrong algorithm and similar issues. Which ones are you getting?
When it comes to HW errors, read my post above.
If you understand how stratum protocol works, how job delegation is performed, then you can clearly understand that ANY job throw at miner HAS to be performed with 0 HW errors. What is job at all? It is a string of data, that is being "hashed". Now you tell me, how can this string of data affect HW error rate? The only explanation is bad mining software that is perhaps incapable of doing fast work switch thus doing some nasty things it shouldn't (overwrites?) which results in HW errors thus rejected shares.
Unfortunately, we cannot control what kind of orders are put on NiceHash and some buyers put orders with fast work switching pools.
You have two types of rejects; stale share and share below target. First one happens when you are too late to the party (basically, too high ping from you to the pool), second one happens due to incorrect configurations, wrong algorithm and similar issues. Which ones are you getting?
When it comes to HW errors, read my post above.
If you understand how stratum protocol works, how job delegation is performed, then you can clearly understand that ANY job throw at miner HAS to be performed with 0 HW errors. What is job at all? It is a string of data, that is being "hashed". Now you tell me, how can this string of data affect HW error rate? The only explanation is bad mining software that is perhaps incapable of doing fast work switch thus doing some nasty things it shouldn't (overwrites?) which results in HW errors thus rejected shares.
Unfortunately, we cannot control what kind of orders are put on NiceHash and some buyers put orders with fast work switching pools.
Shouldn't you be able to pick one address from your database with a high reject rate and find out what the pool is getting from the miner? Anyway, here it is:
Code:
[01:09:53] Stratum from Pool 0 requested work restart
[01:09:53] Pool 0 stale share detected, submitting as user requested
[01:09:53] Pool 0 stale share detected, submitting as user requested
[01:09:53] Rejected 038413a0 Diff 1.03K/128 GPU 0 Pool 0 (Job not found.)
[01:09:53] Rejected 024cb076 Diff 304/128 GPU 1 Pool 0 (Job not found.)
Code:
Round started UTC 2014-04-28 18:17:38
Round accepted GH 43.60
Round rejected GH 7.52 (14.70%)
Now I don't know how else I could possibly convey to you that Gridseed HWs are not necessarily hardware errors, but possibly rejects/stales by another name, so lets not bother with that. I'm not too fond of their software either so let's blame it
The above is from an R9 rig with zero HWs, so nothing to do with Gridseeds anyway. Just give me a reasonable explanation how a perfectly fine mining rig can have a 10-15% sustained reject rate on nicehash but not on any other pool, and - more importantly - way above what you have stated "plenty of miners" are having. If it's geography maybe it's time to consider multiple endpoints. If it's something else I would like to know and I think I'm not alone. I can poke in the dark here trying different rigs and even different locations but that's a waste of time.
April 28, 2014, 05:00:15 PM
And that boils down to bad mining software, nothing else.
I don't know how you got that from my explanation. If you take a perfectly fine Gridseed farm that gets 2% rejects on a regular pool, point it to nicehash, and start getting 10%+ rejects, how is that "nothing else"? All I was saying, that with Gridseeds HWs are not the same as with GPUs, and yes the software is brain dead for reporting them that way, but they are not caused by said software. The fact is that nicehash in some cases produces a significantly higher reject rate than other pools. I would like to have these cases isolated, explained, and possibly fixed, rather than dismissed as "bad mining software". And by the way my own experience shows high reject rates with the latest sgminer on an R9 rig, so clearly not Gridseed or software issue.
+1
I know nothing about mining or stratum protocols. All I can do is share my observation that I get EXTREME HW and rejects ONLY when pointed at Nicehash. I can mine with no HW and <2% rejects when mining at coinshift, coinfu, weminall, etc with no settings or hardware changes on my end. I'm not defending Hashra's controller or BFGMiner, but just hoping that someone can agree with my observations or point me in the direction of a solution.
April 28, 2014, 04:43:06 PM
Are you talking about rejects or HW errors. Let's not make this the same thing.
You have two types of rejects; stale share and share below target. First one happens when you are too late to the party (basically, too high ping from you to the pool), second one happens due to incorrect configurations, wrong algorithm and similar issues. Which ones are you getting?
When it comes to HW errors, read my post above.
If you understand how stratum protocol works, how job delegation is performed, then you can clearly understand that ANY job throw at miner HAS to be performed with 0 HW errors. What is job at all? It is a string of data, that is being "hashed". Now you tell me, how can this string of data affect HW error rate? The only explanation is bad mining software that is perhaps incapable of doing fast work switch thus doing some nasty things it shouldn't (overwrites?) which results in HW errors thus rejected shares.
Unfortunately, we cannot control what kind of orders are put on NiceHash and some buyers put orders with fast work switching pools.
You have two types of rejects; stale share and share below target. First one happens when you are too late to the party (basically, too high ping from you to the pool), second one happens due to incorrect configurations, wrong algorithm and similar issues. Which ones are you getting?
When it comes to HW errors, read my post above.
If you understand how stratum protocol works, how job delegation is performed, then you can clearly understand that ANY job throw at miner HAS to be performed with 0 HW errors. What is job at all? It is a string of data, that is being "hashed". Now you tell me, how can this string of data affect HW error rate? The only explanation is bad mining software that is perhaps incapable of doing fast work switch thus doing some nasty things it shouldn't (overwrites?) which results in HW errors thus rejected shares.
Unfortunately, we cannot control what kind of orders are put on NiceHash and some buyers put orders with fast work switching pools.
April 28, 2014, 04:17:19 PM
And that boils down to bad mining software, nothing else.
I don't know how you got that from my explanation. If you take a perfectly fine Gridseed farm that gets 2% rejects on a regular pool, point it to nicehash, and start getting 10%+ rejects, how is that "nothing else"? All I was saying, that with Gridseeds HWs are not the same as with GPUs, and yes the software is brain dead for reporting them that way, but they are not caused by said software. The fact is that nicehash in some cases produces a significantly higher reject rate than other pools. I would like to have these cases isolated, explained, and possibly fixed, rather than dismissed as "bad mining software". And by the way my own experience shows high reject rates with the latest sgminer on an R9 rig, so clearly not Gridseed or software issue.
April 28, 2014, 04:03:52 PM
HW errors mark either real hardware errors or wrong configuration of mining software. No wonder you are getting rejects. You should fix the hardware/software, then reject rate will drop down.
Well if you read my post, you'll see that I mined at another pool to verify that my hardware and software were fine. It is a problem with Nicehash not playing nice with Hashra Controlla.
If this was general issue of NiceHash, then everone would be having such bad reject rate, but there are plenty of miners with less than 1% of rejects, often 0%.
Your miner should not provide any HW errors, regardless of what data is being sent from the pool. If the data type effects HW error rate, this is clearly a software issue on your side. HW errors on miners tell you about concurrency threads data overlapping thus causing errors. This is due to malconfiguration in most cases (on standard GPU cards, you get this when you set incorrect thread concurrency according to intensity, but more can miner devs tell you about this).
On Gridseeds HW errors are not necessarily hardware errors. Yes, it's stupid like that. A quick experiment can prove that - unplug the network cable of a few seconds, plug it back in, HW may start showing up if the gridseed returns hashes for the work that is not valid anymore. In other words, connectivity or other issues that cause rejects may as well be causing HW on Gridseeds .
And that boils down to bad mining software, nothing else.
April 28, 2014, 03:15:28 PM
HW errors mark either real hardware errors or wrong configuration of mining software. No wonder you are getting rejects. You should fix the hardware/software, then reject rate will drop down.
Well if you read my post, you'll see that I mined at another pool to verify that my hardware and software were fine. It is a problem with Nicehash not playing nice with Hashra Controlla.
If this was general issue of NiceHash, then everone would be having such bad reject rate, but there are plenty of miners with less than 1% of rejects, often 0%.
Your miner should not provide any HW errors, regardless of what data is being sent from the pool. If the data type effects HW error rate, this is clearly a software issue on your side. HW errors on miners tell you about concurrency threads data overlapping thus causing errors. This is due to malconfiguration in most cases (on standard GPU cards, you get this when you set incorrect thread concurrency according to intensity, but more can miner devs tell you about this).
On Gridseeds HW errors are not necessarily hardware errors. Yes, it's stupid like that. A quick experiment can prove that - unplug the network cable of a few seconds, plug it back in, HW may start showing up if the gridseed returns hashes for the work that is not valid anymore. In other words, connectivity or other issues that cause rejects may as well be causing HW on Gridseeds .
April 28, 2014, 02:20:35 PM
HW errors mark either real hardware errors or wrong configuration of mining software. No wonder you are getting rejects. You should fix the hardware/software, then reject rate will drop down.
Well if you read my post, you'll see that I mined at another pool to verify that my hardware and software were fine. It is a problem with Nicehash not playing nice with Hashra Controlla.
If this was general issue of NiceHash, then everone would be having such bad reject rate, but there are plenty of miners with less than 1% of rejects, often 0%.
Your miner should not provide any HW errors, regardless of what data is being sent from the pool. If the data type effects HW error rate, this is clearly a software issue on your side. HW errors on miners tell you about concurrency threads data overlapping thus causing errors. This is due to malconfiguration in most cases (on standard GPU cards, you get this when you set incorrect thread concurrency according to intensity, but more can miner devs tell you about this).
April 28, 2014, 02:15:19 PM
I am running the latest version (1.4.0) in scrypt only mode. The log shows bfgminer as well.
April 28, 2014, 02:09:41 PM
Well if you read my post, you'll see that I mined at another pool to verify that my hardware and software were fine. It is a problem with Nicehash not playing nice with Hashra Controlla.
Please verify that you're using the Hashra Controlla version with BFGMiner. The latest version supports scrypt only (bfgminer), SHA-256 (cgminer) only or dual-mining mode (cpuminer + cgminer), and since cpuminer and cgminer3.7.2 is not supported with NiceHash, you should run the scrypt-only version with BFGMiner. If you can, please verify that your using the version with bfgminer and please report if you had any success, any feedback is appreciated. Thanks!
April 28, 2014, 02:02:56 PM
HW errors mark either real hardware errors or wrong configuration of mining software. No wonder you are getting rejects. You should fix the hardware/software, then reject rate will drop down.
Well if you read my post, you'll see that I mined at another pool to verify that my hardware and software were fine. It is a problem with Nicehash not playing nice with Hashra Controlla.
April 28, 2014, 01:55:12 PM
There are some decent paying Scrypt-A-Nfactor orders ... if you have Scrypt-A-Nfactor you can get some good payouts, check here: https://www.nicehash.com/index.jsp?a=2 and point your miner to stratum+tcp://stratum.nicehash.com:3335
We advice you to use multi-algorithm configuration (if you're using latest sgminer)
"pools" : [
{
"name" : "NiceHash Scrypt-A.-Nfactor",
"url" : "stratum+tcp://stratum.nicehash.com:3335",
"user" : "myBTCaddress",
"algorithm" : "nscrypt",
"nfactor" : "11"
},
{
"name" : "NiceHash Scrypt",
"url" : "stratum+tcp://stratum.nicehash.com:3333",
"user" : "myBTCaddress",
},
{
"name" : "mybackuppool",
"url" : "stratum+tcp://mybackuppool",
"user" : "myBTCaddress",
"pass" : "x"
}
]
,
"kernel" : "zuikkis",
... etc ...
We advice you to use multi-algorithm configuration (if you're using latest sgminer)
"pools" : [
{
"name" : "NiceHash Scrypt-A.-Nfactor",
"url" : "stratum+tcp://stratum.nicehash.com:3335",
"user" : "myBTCaddress",
"algorithm" : "nscrypt",
"nfactor" : "11"
},
{
"name" : "NiceHash Scrypt",
"url" : "stratum+tcp://stratum.nicehash.com:3333",
"user" : "myBTCaddress",
},
{
"name" : "mybackuppool",
"url" : "stratum+tcp://mybackuppool",
"user" : "myBTCaddress",
"pass" : "x"
}
]
,
"kernel" : "zuikkis",
... etc ...
April 28, 2014, 07:33:02 AM
HW errors mark either real hardware errors or wrong configuration of mining software. No wonder you are getting rejects. You should fix the hardware/software, then reject rate will drop down.
April 27, 2014, 10:28:37 PM
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.
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.
Jump to: