Author

Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 342. (Read 794443 times)

hero member
Activity: 700
Merit: 500
phzi, are you reading my mind? Wink 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.
sr. member
Activity: 457
Merit: 273
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? Wink 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!
hero member
Activity: 700
Merit: 500
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.
sr. member
Activity: 457
Merit: 273
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.
member
Activity: 95
Merit: 10
You can lower your share diff with "d=128" or whatever you want as password, so you submit shares more often you know.
hero member
Activity: 700
Merit: 500
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.
legendary
Activity: 1050
Merit: 1000
Mine the hottest new coins at ipoMiner.com
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.
member
Activity: 96
Merit: 10
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!
sr. member
Activity: 457
Merit: 273
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
sr. member
Activity: 457
Merit: 273
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.
full member
Activity: 210
Merit: 100
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
}
sr. member
Activity: 457
Merit: 273
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!
legendary
Activity: 1050
Merit: 1000
Mine the hottest new coins at ipoMiner.com
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 from it though. I can set the share diff as high as 1024, if that matters, but I don't think it should matter.

I just cancelled my current order and withdrew my coins - this has been a ripoff.
sr. member
Activity: 457
Merit: 273
@kenshirothefist I don't think that's the issue.. it was definitely running for 30+ minutes.

It's still possible that some order intercalated between your order (small higher paying order) .. What pool were you mining at, do you know what is pools's highest share diff?
legendary
Activity: 1050
Merit: 1000
Mine the hottest new coins at ipoMiner.com
@kenshirothefist I don't think that's the issue.. it was definitely running for 30+ minutes.
full member
Activity: 307
Merit: 102
It is around 130MH/s, usually you have to let it run for some time to see the real hashrate.
Quote
Hashrate based on shares submitted in the past 5 minutes.

Also, 0.008BTC/MH? WTF?  Grin

Edit: Oh, now it's 0.010BTC/MH, okay.

i cant believe it either , but as of now nicehash is the best paying pool anywhere
sr. member
Activity: 457
Merit: 273
How does the displayed hashrate on NiceHash work, exactly? I'm renting, and see an scrypt speed of 0.1345 GH/s listed, but only see 16MH/s on my pool. I would expect to see 134.5MH/s...

NiceHash calculates hashrate based on shares submitted in the past 5 minutes. Most pools calculates hashrate based on shares submited in the past 10+ minutes. What happend to you is that probably your order wasn't running long enough for your pool to display full hashrate.
sr. member
Activity: 266
Merit: 250
It is around 130MH/s, usually you have to let it run for some time to see the real hashrate.
Quote
Hashrate based on shares submitted in the past 5 minutes.

Also, 0.008BTC/MH? WTF?  Grin

Edit: Oh, now it's 0.010BTC/MH, okay.
legendary
Activity: 1050
Merit: 1000
Mine the hottest new coins at ipoMiner.com
How does the displayed hashrate on NiceHash work, exactly? I'm renting, and see an scrypt speed of 0.1345 GH/s listed, but only see 16MH/s on my pool. I would expect to see 134.5MH/s...
sr. member
Activity: 457
Merit: 273
I am getting only rejected : Rejected 39047b86 Diff 1.15K/128 GPU 1 Pool 3 (Share above target.)
My friends reported the same with cgminer. Is there any problem on scrypt stratum ?

cgminer does not work, try sgminer :-)

True, cgminer 3.7.2 has a bug and doesn't work with our stratum (Due to the NiceHash's latest state-of-the art engine, older miners are not supported.) ... please read https://www.nicehash.com/index.jsp?p=faq#faqs0 ... you'll find detailed information on which miners are supported (basically all except of cgminer 3.7.2 Wink ). You'll also find some useful information on how to configure your miners, how to squeeze some more hashrate by using optimized kernels, etc.
Jump to: