Post
Topic
Board Mining (Altcoins)
Re: [ANN] TeamRedMiner - CNv8 - Vega 64 2200+h/s Rx470 1025+h/s Low Power Draw
by
kerney666
on 02/11/2018, 18:01:53 UTC
Is nicehash supported?  Huh

Sure, Nicehash works.

Like joseph32 writes, it is supported. However, I'm not a big fan of Nicehash in the CN world. We need to support it though since it's the same mechanism that proxies like xmrig-proxy use as well.

Modifying a reply I wrote earlier today in our other ann thread that explains why it's a bad idea imho:

NiceHash mining is a little problematic with CN. Calculating a round of hashes for CN takes > 1 sec, which is a very long processing time. For other hash functions numbers in a few ms are more common. So, CN has a much higher probability of your hashes being stale when the gpu job completes. The more often your pool/NiceHash sends out new jobs, the higher the probability that calculated shares belong to a stale job. For e.g. direct XMR mining (a coin with 2 min block time), pools are generally nice about accepting shares for both the current and the previous pool job as long as the new job wasn't sent out as a reaction to a new network block. The more common reason for a new job is just an ntime roll forward in time. In that case, the shares you submit for the previous job are still possible to convert into a network block, so pools should really accept them. With a 2 min block time, these type of new jobs will be sent out (on average) every 2 mins. Given this, we can expect to have maybe between 0.5-1% rejected shares over time. Some pools accept shares for stale jobs anyway to be nice.

For NiceHash, this just isn’t true. They can throw you around between client orders every 5 secs and generally seem to be more picky with stale shares. Using the same style of mining as for normal pools, you will see a much higher reject ratio. They have pushed the cost of the long CN calculation period for gpus onto miners. Clients only pay for accepted shares. CPU miners will be fine though. One approach to dealing with NiceHash is an abort mechanism, i.e. as soon as a new job comes in you abort any ongoing calculations and restart with the new job instead. However, this means that the last ~0.5 secs of gpu time (on avg) will be wasted for every job switch. The more often new jobs are sent out, the more gpu time you will waste, so it’s not 100% sure you’ll be better off with this approach anyway.

In the end, maybe NiceHash will give you a higher return anyway due to an implicit profit switching between CNv8 coins, but when using this miner in its current form, you will lose a few pcts of hashrate in rejected shares.