[ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool

[Degolep]

Does anyone have an idea why do I with my 280x only 550Mh/s with sgminer but with old cgminer 3.7.2 I get 715Mh/s? I've tryed it all changing kernels, intensity, xintensity...

Code:

"xintensity" : "4",
"worksize" : "128",
"kernel" : "ckolivas",
"lookup-gap" : "2",
"thread-concurrency" : "8193",
"shaders" : "0",
"gpu-threads" : "2",
"api-mcast-port" : "4028",
"api-port" : "4028",
"expiry" : "10",
"failover-switch-delay" : "60",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "7",
"tcp-keepalive" : "30",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin",
"no-client-reconnect" : true
}

[kenshirothefist]

It is my pool - ipoMiner.com. I'm currently the top bidder on NiceHash and have been for a while now, again, and am seeing 0.19GH/s on NiceHash - only 23MH on the pool-side for that worker though. I can set the share diff as high as 1024, if that matters, but I don't know why it would.

Well, we'll take a closer look at this, I'll pass this to the dev team and get back to you via PM or email as soon as we'll find out why the numbers doesn't match. Thanks for your patience!

We found out that there was another user having issues with ipominer.com, also couldn't max out more then 30mhs ... You should know that our system aggregates the hash power and connects to the pool with a single connection (this is more efficient and eliminates false-ddos like issues with pools in case of many smaller connections). It looks that the https://ipominer.com/ pool can't handle massive hash power through single connection (this is different than having multiple rigs with same username/password/account). Please check with the software provider of your pool what are the limitations for a single connection to your pool. Of course I'm not saying there is something wrong with your pool, it's just that it can't handle massive hash rate through a single connection. Probably there are some other pools with similar limitations, but so far we've successfully tested many other pools with 100mhs+ on single connection.

Related: as you can see we're exploring new dimensions regarding pool's capabilities. We're the first in market to be able to provide truly massive hash rate through single connection, but soon this will become a standard, when ASICs like KnCMiner, Alpha Technology and next-gen GridSeeds will become available. Therefore I ask all pool operators to make sure their pools are able to accept and handle massive hash rate through a single connection.

[kenshirothefist]

Does anyone have an idea why do I with my 280x only 550Mh/s with sgminer but with old cgminer 3.7.2 I get 715Mh/s? I've tryed it all changing kernels, intensity, xintensity...

Make sure sgminer truly loads all the settings from config file. You can start sgminer with the --text-only option and also with the --verbose option ... this way you'll be able to see which part of config might not be properly loaded.

sgminer --text-only --verbose ... other parameters

"thread-concurrency" : "8193",

why 8193? try 8192

[dhsc19]

I'm very impressed with this concept.  So, if I understand it correctly NiceHash merely operates as a "hub" where the rig owner and the hash renter converge in a mutually beneficial trade of resources.  I like the fact that this method takes control away from a singular data center and puts the power back to the individual.  I'm busy mining my "minimum" on my current pool.  Once I can cash out completely, I am moving my miners over NiceHash!

[ipominer]

I did see around 125MH/s from NiceHash at one point earlier today after it had been mining for around an hour, but the majority of the time I saw roughly 1/10 the promised hashrate.

I've also previously run >70MH/s myself through a single connection to ipoMiner without issue.

I got an email from someone that was mining on NiceHash at the time I had it rented, and they said they were seeing rejects in their miner, if that helps clarify the issue for you at all.

I thought the issue might be worker banning because of duplicate shares, and I do see that in the log files occasionally, but only a few times.. not nearly enough to cause this hashrate discrepancy.

[phzi]

Been trying NiceHash out recently, and overall it's great.  However, non-payment for stale shares makes this site extremely hokey.  Why?  Because if someone pays to direct hashrate to an extremely low diff coin, you activity like this:

Code:

[19:48:54] Stratum from NiceHash requested work restart
[19:48:54] Stratum from NiceHash detected new block
[19:48:56] Stratum from NiceHash requested work restart
[19:48:56] Stratum from NiceHash detected new block
[19:48:57] Stratum from NiceHash requested work restart
[19:48:57] Stratum from NiceHash detected new block
[19:48:57] Stratum from NiceHash requested work restart
[19:48:59] Stratum from NiceHash requested work restart
[19:48:59] Stratum from NiceHash detected new block
[19:48:59] Rejected 5aecc399 Diff 721/512 GPU 2  (Job not found.)
[19:49:01] Stratum from NiceHash requested work restart
[19:49:01] Stratum from NiceHash detected new block
[19:49:03] Stratum from NiceHash requested work restart
[19:49:03] Stratum from NiceHash detected new block
[19:49:03] Rejected 1908fd32 Diff 2.62K/512 GPU 4  (Job not found.)
[19:49:03] Stratum from NiceHash requested work restart
[19:49:04] Stratum from NiceHash requested work restart
[19:49:04] Stratum from NiceHash detected new block
[19:49:06] Stratum from NiceHash requested work restart
[19:49:06] Stratum from NiceHash detected new block
[19:49:08] Stratum from NiceHash requested work restart
[19:49:08] Stratum from NiceHash detected new block
[19:49:08] Stratum from NiceHash requested work restart
[19:49:09] Stratum from NiceHash requested work restart

When this site pushes so much hashrate to a low-diff coin like this, reject rates go thru the roof, and the actual payout is abimismal.  Meanwhile, the person paying for hashes gets up to 50% "bonus" hashrate because most shares are rejected.

I am going to move my rigs away from here until this is fixed, but I am definitely going to start buying lots of hashing time for low-diff coins that seem valuable...

I think a change is needed here if you don't want this site to get gamed badly and fail.  Either average reject rate needs to be considered, and the person paying for mining power should pay based on that average reject rate (individual miners with higher reject rates should get less of course).  Or, NiceHash should avoid piling all of the pool's hashing power on a job when the difficult is so low that we compete with ourselves for orphans.

[hutnik]

You can lower your share diff with "d=128" or whatever you want as password, so you submit shares more often you know.

[kenshirothefist]

Been trying NiceHash out recently, and overall it's great.  However, non-payment for stale shares makes this site extremely hokey.  Why?  Because if someone pays to direct hashrate to an extremely low diff coin, you activity like this:

When this site pushes so much hashrate to a low-diff coin like this, reject rates go thru the roof, and the actual payout is abimismal.  Meanwhile, the person paying for hashes gets up to 50% "bonus" hashrate because most shares are rejected.

I think a change is needed here if you don't want this site to get gamed badly and fail.  Either average reject rate needs to be considered, and the person paying for mining power should pay based on that average reject rate (individual miners with higher reject rates should get less of course).  Or, NiceHash should avoid piling all of the pool's hashing power on a job when the difficult is so low that we compete with ourselves for orphans.

You're partly right about this. Please, take a look at FAQ (you probably already did) "How exactly does pay-per-valid-share and get-paid-per-valid share work?" - https://www.nicehash.com/index.jsp?p=faq#faqg2

We'll make sure it's a 100% fair game for sellers and buyers. Currently we've already resolved all the issues regarding general validation of the shares and this is already implemented. Provider is paid for all valid work it produces (even if some of this valid work is rejected by the buyers pool, because pool is not operating correctly).

What we're currently working on is better validation of stale shares. When a buy order is set to a pool that produces excessive stale shares on the provider side, provider is actually not being paid for those stale shares. However, even without intelligent stale shares detection we're not talking about 50% rejects but more like 5-10% worst-case scenarios. But this is the exact same reject rate that a provider would have to "swallow" if you would be mining on any other pool or multipool which is hitting high-profitability fast-switching low-diff coins. But since our service is about renting (valid) hash power, buyer should pay for all the valid work that he gets, even if these are stale shares (buyer is the one that chooses a pool that produces stale shares) - therefore we'll improve this.

Anyway - stale shares validation is currently being tested - will let you know when it's fully implemented.

[phzi]

You can lower your share diff with "d=128" or whatever you want as password, so you submit shares more often you know.

I fail to understand how this is relevant to anything?  Share difficulty affects ONLY variance.  It has NOTHING to do with reject rates (a miner at 2048 diff vs 64 diff will be discover an identical number of valid shares, statistically speaking).

You're partly right about this. Please, take a look at FAQ (you probably already did) "How exactly does pay-per-valid-share and get-paid-per-valid share work?" - https://www.nicehash.com/index.jsp?p=faq#faqg2

Appreciate the link.  I did read everything on the site, and this entire thread before I directed any hashing power here, however.

We'll make sure it's a 100% fair game for sellers and buyers. Currently we've already resolved all the issues regarding general validation of the shares and this is already implemented. Provider is paid for all valid work it produces (even if some of this valid work is rejected by the buyers pool, because pool is not operating correctly).

Be nice if it was true...  So far it certainly doesn't seem that way.  You want fair?  Then you need to implement a straight forward reject scheme such as, "shares submitted >1200ms after validity will be rejected".  If you base rejects on the last block found, then you will never have a fair system, because that fairness will be completely destroyed when low-diff coins are mined.  Otherwise, the highest BTC/MH job won't actually yield the highest BTC/MH, rendering this pool's entire work prioritization scheme broken.  If the pool it putting enough hashrate on a job to orphan it's own blocks (I saw at least a dozen shares from my rigs that were valid blocks get rejected in under 2 minutes at one point!), then the pool is not operating optimally or IMO even within acceptable operating tolerances.

What we're currently working on is better validation of stale shares. When a buy order is set to a pool that produces excessive stale shares on the provider side, provider is actually not being paid for those stale shares. However, even without intelligent stale shares detection we're not talking about 50% rejects but more like 5-10% worst-case scenarios.

Try 10% minimum.  With properly tuned rigs that average <1% on most constant coin pools, and <3% on multi-pools, over the last 24hr I am getting >10% rejects here.  And for several periods where there were high-diff coins getting mined... it was > 40% rejects for several minutes!!!

But this is the exact same reject rate that a provider would have to "swallow" if you would be mining on any other pool or multipool which is hitting high-profitability fast-switching low-diff coins. But since our service is about renting (valid) hash power, buyer should pay for all the valid work that he gets, even if these are stale shares (buyer is the one that chooses a pool that produces stale shares) - therefore we'll improve this.

It is the amount that the person mining has to "swallow" when mining at a multi-pool, definitely!  The person MINING at the pool must swallow, being key.  The buyer is the person mining at a pool in this case, and they should be swallowing the cost of rejects due to their pool choice.  NOT the miner.  Otherwise, you need to allow miners to exclude jobs, or only select the jobs they want.

Anyway - stale shares validation is currently being tested - will let you know when it's fully implemented.

Glad to hear this is still being worked on.  I will definitely keep an eye and a few MH here for monitoring purposes.

---

Overall tho, I have to warn the majority of miners to be careful of this pool for now.  Due to the "we penalize only the miner for rejects" scheme, even with a properly tuned rig at low intensity you will see > 10% rejects at NiceHash.com.  I provided a large portion of his pool's hashing power (around 10%) for over 24 hours, and my with response tuned miners (low intensity, tuned down even), reject rate has been >11% on average.  This is completely unacceptable and needs to be fixed.  I would have made more mining at WafflePool for the same period, once you account for the reject rate.

NiceHash badly needs to adjust their reject scheme to at least partially penalize the buyer for choosing a high-reject pool or coin before this can possibly be a viable system.  Penalizing the hash provider based on the buyer's decision to mine a low-diff shit coin is absolutely ridiculous.  It would make significantly more sense to charge based on average reject rate, vs 0% reject rate.

---

I think your definition of "valid" hashpower needs to change if this model is to remain viable.  And I say this not because I wish to attack this site, but rather because I would like to see it succeed.

---

One more question:
The pool regularly stops accepting hashes for up to 10 seconds at a time:

Code:

[17:22:13] stratum.nicehash.com not responding!
<...>
[17:22:22] Work available from pools, resuming.

I presume this happens on job switches due to an inefficiency in the stratum implementation?  Regularly losing 10 seconds of work sucks quite badly, and is costing rigs here an extra percent or so of potential profit.

[kenshirothefist]

We'll make sure it's a 100% fair game for sellers and buyers. Currently we've already resolved all the issues regarding general validation of the shares and this is already implemented. Provider is paid for all valid work it produces (even if some of this valid work is rejected by the buyers pool, because pool is not operating correctly).

Be nice if it was true...  So far it certainly doesn't seem that way.  You want fair?  Then you need to implement a straight forward reject scheme such as, "shares submitted >1200ms after validity will be rejected".

phzi, are you reading my mind? That's exactly what we've been working on recently. We've implemented the first version of reject scheme and now you should see a lot less rejects. We've updated our stale shares detection about 15 minutes ago. Please check the reject rate in the past 10 minutes and let me know if it is any better (also check your graphs stats on NiceHash).

One more question:
The pool regularly stops accepting hashes for up to 10 seconds at a time:

Code:

[17:22:13] stratum.nicehash.com not responding!
<...>
[17:22:22] Work available from pools, resuming.

I presume this happens on job switches due to an inefficiency in the stratum implementation?  Regularly losing 10 seconds of work sucks quite badly, and is costing rigs here an extra percent or so of potential profit.

Yeah, this issue was due to "partly-bad" end-point pools ... It's easy to detect when pool is really bad or really good, the tricky part is to detect when pool is "swapping". We also improved this - let me know if you still see "not responding" messages.

Thanks for your feedback!

[phzi]

phzi, are you reading my mind? That's exactly what we've been working on recently. We've implemented the first version of reject scheme and now you should see a lot less rejects. We've updated our stale shares detection about 15 minutes ago. Please check the reject rate in the past 10 minutes and let me know if it is any better (also check your graphs stats on NiceHash).

Heh, awesome.  Reject rates seem to have dropped into much more acceptable territory!  Nice work.  I will monitor for the next 24hr and try to remember to post again.

Yeah, this issue was due to "partly-bad" end-point pools ... It's easy to detect when pool is really bad or really good, the tricky part is to detect when pool is "swapping". We also improved this - let me know if you still see "not responding" messages.

Thanks for your feedback!

Thanks for listening.  Looking forward to seeing this pool grow.

[TheMathGuy]

Man, this pool (or hashrate exchange) is amazing! Especially the part where you can set both your minimum prize and diff as just your password.
Also, Since the last update my reject rates dropped to 0.5% from 5-7% earlier, keep up the good work!

[twobitlolz]

can anyone (kenshirothefist: *poke*) summarize the problem with cgminer 3.7.2 and NiceHash's scrypt pool, point out the breaking commit (between cgminer 3.1.1 and 3.7.2) or the fix (in sgminer) relating to it?

btw, great job on this service so far! it's great to see some innovative new pool ideas this year

[phzi]

can anyone (kenshirothefist: *poke*) summarize the problem with cgminer 3.7.2 and NiceHash's scrypt pool, point out the breaking commit (between cgminer 3.1.1 and 3.7.2) or the fix (in sgminer) relating to it?

btw, great job on this service so far! it's great to see some innovative new pool ideas this year

cgminer 3.7.2 has many many bugs that have since been patched in newer versions and branches such as sgminer.  There's really no good reason to be using an old version of cgminer anymore - switch to sgminer.

---

Everytime the pool switches jobs, it seems to disconnect all my miners briefly.  Lost mining time appears to be 1-5 seconds everytime, but any work that was performed immediately prior is lost as well.  And sometimes when there are a bunch of small jobs, or several new jobs are posted in short succession, this is a pretty significant loss of hashrate.  It's super obvious for me, because the R9 290 fans spin up slightly when the GPU isn't under load (noise change is very noticeable).  With NiceHash, I hear the rig in my living room drop for a a few seconds several times in a minute sometimes.

I see this regularly on my consoles:

Code:

[21:50:14] Stratum connection to NiceHash interrupted
[21:50:15] NiceHash difficulty changed to 512

Code:

[21:50:14] Stratum connection to NiceHash interrupted
[21:50:14] NiceHash stratum share submission failure
[21:50:15] NiceHash difficulty changed to 512
[21:50:19] Network diff set to 84.7M
[21:50:19] New block detected on network before pool notification
[21:50:19] NiceHash communication resumed, submitting work
[21:50:20] Rejected 01529678 Diff 49.5K/512 GPU 1 NiceHash (Job not found.)

Code:

[22:08:30] Stratum connection to NiceHash interrupted
[22:08:31] NiceHash stratum share submission failure
[22:08:31] NiceHash difficulty changed to 32
[22:08:32] NiceHash difficulty changed to 64
[22:08:32] Network diff set to 10.4M
[22:08:32] Stratum from NiceHash detected new block
[22:08:32] Stratum from NiceHash requested work restart
[22:08:36] NiceHash communication resumed, submitting work
[22:08:36] Rejected cf84d7c0 Diff 316/32 GPU 4 NiceHash (Job not found.)

Code:

[22:08:30] Stratum connection to NiceHash interrupted
[22:08:30] Lost 2 shares due to stratum disconnect on NiceHash
[22:08:31] NiceHash stratum share submission failure
[22:08:31] NiceHash difficulty changed to 32
[22:08:32] NiceHash difficulty changed to 64
[22:08:32] Network diff set to 10.4M
[22:08:32] Stratum from NiceHash detected new block
[22:08:32] Stratum from NiceHash requested work restart
[22:08:36] NiceHash communication resumed, submitting work
[22:08:36] Rejected 04c785be Diff 54/32 GPU 3 NiceHash (Job not found.)
[22:08:36] Rejected 06e87f69 Diff 37/32 GPU 0 NiceHash (Job not found.)

Code:

[22:08:30] Stratum connection to NiceHash interrupted
[22:08:30] Lost 1 shares due to stratum disconnect on NiceHash
[22:08:30] NiceHash stratum share submission failure
[22:08:31] NiceHash difficulty changed to 32
[22:08:32] NiceHash difficulty changed to 64
[22:08:32] Network diff set to 10.4M
[22:08:32] Stratum from NiceHash detected new block
[22:08:32] Stratum from NiceHash requested work restart
[22:08:35] NiceHash communication resumed, submitting work
[22:08:36] Rejected 02350f7d Diff 116/32 GPU 2 NiceHash (Job not found.)
[22:08:36] Rejected 07b180d4 Diff 33/32 GPU 4 NiceHash (Job not found.)

There's no reason for the stratum server to be disconnecting miners like this when switching jobs.  Please fix.

Also, the server has been dropping me to down to low-diff on reconnects sometimes, even thought I have p=5.0;d=512 set as my password.

---

Edit: just observed 3 connection drops within 20 seconds.

[suchmoon]

can anyone (kenshirothefist: *poke*) summarize the problem with cgminer 3.7.2 and NiceHash's scrypt pool, point out the breaking commit (between cgminer 3.1.1 and 3.7.2) or the fix (in sgminer) relating to it?

btw, great job on this service so far! it's great to see some innovative new pool ideas this year

cgminer 3.7.2 has many many bugs that have since been patched in newer versions and branches such as sgminer.  There's really no good reason to be using an old version of cgminer anymore - switch to sgminer.

sgminer doesn't support Gridseed

[kenshirothefist]

can anyone (kenshirothefist: *poke*) summarize the problem with cgminer 3.7.2 and NiceHash's scrypt pool, point out the breaking commit (between cgminer 3.1.1 and 3.7.2) or the fix (in sgminer) relating to it?

The bug we're talking about it related to correct handling of extra nonce 2 (extranonce2, xnonce2) size. In cgminer 3.7.2 xnonce is fixed to 4 ... however by stratum protocol this should be "dynamic/resizable". Well, actually you should ask ckolivas for details regarding that ... I'm not sure in which exact version this was patched but if you can find out I'll be very glad if you'd share the info here.

[phzi]

sgminer doesn't support Gridseed

You can use bfgminer on gridseeds.  At least bfgminer is actively maintained with scrypt support.

[kenshirothefist]

can anyone (kenshirothefist: *poke*) summarize the problem with cgminer 3.7.2 and NiceHash's scrypt pool, point out the breaking commit (between cgminer 3.1.1 and 3.7.2) or the fix (in sgminer) relating to it?

btw, great job on this service so far! it's great to see some innovative new pool ideas this year

cgminer 3.7.2 has many many bugs that have since been patched in newer versions and branches such as sgminer.  There's really no good reason to be using an old version of cgminer anymore - switch to sgminer.

sgminer doesn't support Gridseed

Well, what we're seeing here with this cgminer-3.7.2 is similar to WinXP story ... to many users of too old software, and when support ends it's "Houston, we've got problems"

Anyway, the correct path would be to adopt newer software. The absolute correct path would be for the GridSeed community to step together and build modular approach for GridSeed support in sgminer/bfgminer so that it would be easy for veox/luke-jr to include support for GridSeeds in upstream versions. Not sure how to accomplish that though, community/gridseed users should step together for this.

See FAQ "Which miners are supported?" https://www.nicehash.com/index.jsp?p=faq#faqs0 (BFGMiner is supported)

And if you really want to use cgminer, cgminer-3.1.1 (this version doesn't yet introduce the xnonce2 bug) is also supported (https://github.com/gridseed), but I really don't recommend to use these old versions.

[suchmoon]

sgminer doesn't support Gridseed

You can use bfgminer on gridseeds.  At least bfgminer is actively maintained with scrypt support.

I was just replying to your comment that everybody should switch from cgminer to sgminer - that's valid for GPUs only.

bfgminer has scaleability issues on Windows. Can't run more than a couple of instances, can't run more than ~20 miners. But that's another story, it's not a problem with nicehash.

[suchmoon]

Anyway, the correct path would be to adopt newer software. The absolute correct path would be for the GridSeed community to step together and build modular approach for GridSeed support in sgminer/bfgminer so that it would be easy for veox/luke-jr to include support for GridSeeds in upstream versions. Not sure how to accomplish that though, community/gridseed users should step together for this.

Just to clarify: sgminer for Gridseed will not happen:
https://github.com/veox/sgminer/issues/154