Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 106. (Read 211877 times)

We will speed up our cpu code properly, we just didn't have the time for it with this release.

Overclocked cards are not bad in itself as long as they aren't pushed so hard they generate hw errs. Do you see any counts in the "hw" category when the hashrate stats are displayed?

I didn't understand all of this. But I must notice that on other miners not so much rejected shares on nicehash. Speed on cnr on this miners is slower but lower rejected shares and lower fee can do the profit higher...
Thanks for option --no_cpu_check. I'll try it. But I use overclocked cards, so this may not help... Anyway I'll try it.

Ok, so a quick recap on the Nicehash and Nanopool issues.

In short, there are a few different strategies used by pools for (valid) submitted shares belonging to an old job:

• (1) Reject all shares.
• (2) Reject the share if the old job was for a different network block height, otherwise accept.
• (3) Accept all shares (unless some crazy amount of time has passed or the job is very old).

Nicehash is (1), Nanopool also seems to be (1), supportxmr is (3). The proper pool implementation, imho, is (2) since all such shares can still be used to create a network block. (1) is the safe play for the pool, but NOT nice for gpu miners doing CN.

The reason for this is that it takes 1.8-2.2 secs on both Vega and Polaris cards to calculate a wave of hashes. For other compute algos, like lyra2rev3, this time is 20-40ms. Hence, the probability that a new job arrives while you're doing the hash calculations is much much bigger for CN, and for pools like Nicehash you will for sure see a higher reject ratio. Note that this goes for all CN gpu miners.

The issue is also amplified by Nicehash often sending out new jobs more often than "normal" pools. Also, in this miner we currently submit every share, even though it's stale. I'm not sure xmrig does that, which means you will see fewer rejects. That does not imply a higher amount of accepted shares though, the difference is that xmrig threw away shares instead of submiotting and having them rejected.

That said, and as I wrote above, our slower cpu verification will also add latency, which will translate into a higher reject ratio than a faster cpu check, all else being equal. Try running with --no_cpu_check and observe if your reject ratio changes.

In general, I do not really recommend Nicehash gpu mining for CN. Mine the coin(s) directly instead and trade to BTC. They really do penalize gpu miners with their aggressive reject policy. This is regardless of your choice of miner.

The one big difference is that open source miners have excellent cpu code for the algo, borrowed from their cpu miner. For rigs with slow celerons, we will add significant latency with our more naive on-cpu verification. We need to implement automatic generation of x86 machine code for the random ops in CN/r, quite annoying crap to spend time on, but we don’t really have a choice it seems.

Fix for now: if your rig(s) are running without any hw errors, try running with —no_cpu_check. This will disable our check and let the pool run the check instead. Will be fine on most pools and if you don’t oc so much that you get invalid shares that you flood the pool with .

What about high amount of rejects due to "job not found" on nicehash?

4085H/s with 7+7 for 4 GPUs - 1x570, 3x580. Gotta check the power consumption, but the performance seems about the same as CNv8. A job well done!

got this problem only with nanopool

at supportxmr i got no rejected so far after some hours

The real problem is high reject rate. I've switched to XMRig and so far I have 1 reject in almost 2 hours, it sort of shows lower h\r but in the end at pool side it is higher.

Hey guys! Sorry about all the mess with dev pool, there are some issues outside of our control that we are addressing, should hopefully be resolved today. However, I do believe you all see a reconnect within 30 secs or so, so the "reduced rate" period should really be minimal. Let me know if you are experiencing longer disconnected periods than 30-60 secs.

Just tried out the miner and it seems its actually finally making a profit with my power costs. Really crazy how little the power usage and temps are.

Wonder how the difficulty of XMR will eventually settle and wonder how long before the masses start to switch from ETH to XMR mining. Would be nice if we could get this profitability till the end of the month at least.

We really need ETH to switch to ProgPOW soon.

Same problem with Dev pool connection.
 

What option for disable colors? Blue color is very unreadable... (only linux, windows colors - cyan is ok)

Confirm, nicehash cnr mining - many rejected shares - job not found.
And "Dev pool connection was closed by remote side. Mining will proceed at reduced rate etc etc"

still problems with new version...on 3 rigs..2 didnt has the problem until 3 hours ago - with new version also problems with dev pool and all rigs (2 in same facility - one in another)

Todxx, your Lyra2REv3 Dev-Pool is often not available these days, so mining is reduced. Can you please check that?

I have a lot of "job not found" (5%+) on nicehash mining CNvR... with lyra2r3 its way lower

It's almost the same as cnv8.

Monero / XMR miners, what's your hashrate before and after the fork please ?

The hashrate display stopping completely indicates some kind of host-side hang.  We haven't seen this issue recently, but we will look into it.  I can't say that anything we changed in 0.4.1 should affect that.  Please let us know if it happens to you again.

As for the dev pool connection issue, we can't find any problems on our end.  One guess is that because we switched to using port 80 in v0.4.0, some network filters are occasionally killing connections.
In 0.4.1 we switched default port to 4000, if that fails it will try to use port 80 again.

So I'm still running 0.4.0 (because it worked so far)... but I noticed it stopped displaying hashrate info completely after a while.

Is that something that's been fixed in 0.4.1 at all? Haven't seen it in the changelog...

EDIT: could it be related with the miner losing connection to devpool? I'm getting these every now and then:

"Dev pool connection was closed by remote side.
Mining will proceed at reduced rate etc etc"

...shortly followed by "Dev pool connected and ready"

...and hashrate clearly falls on the pool.

Thanks, it works