Author

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

member
Activity: 658
Merit: 86
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.


member
Activity: 658
Merit: 86

I checked with them, seems like you are correct, they have not changed the error message. The rejected shares are due to crappy card quality, not playing nice with the strap. Another thing that i seem to notice is, XMR-Stak was discarding Invalid shares, but logging them regardless, which were equivalent to Hardware Error (HW). But on this fork, instead of being HW, its a Rejected share. I have used the sgminer-gm-5.5.5, and it was doing HWs, instead of rejected shares. Pretty confusing.

I will be checking for the 30/60s stuff for the API.

Thanks for reporting back! In the current version our miner doesn't have cpu verification of the hashes, probably the only one that doesn't. We just send everything to the pool and let them check the shares. We're just about to add the cpu verification parts though, so when that's in place we will be reporting bad shares as "HW errors" as well and not piss of the pool(s) when you push your mem straps too hard Smiley.

jr. member
Activity: 194
Merit: 4

Seems like there are changes on what is transmitted over the API, can you give more information about it?


We haven't changed anything API-related per se, but maybe you're hitting this thing: there is a very confusing design aspect with the sgminer API that we just had to follow to be compatible. The json keys for e.g. avg hashrate last N secs change when you change the period between prints. We did change the default period from 60 secs to 30 secs at some point, so the API keys have changed as well. The proper (and annoying) way to do it is to first send a "config" command, check the reported "Log Interval" value there. That value, in our case "30" for 30 secs, will then be used in the keys for all other messages, for example the "summary" command will return the key ""KHS 30s". Imho it's an idiotic design, but we had to follow it. We have a command line option for changing the period. If there's anything else you're noticing, let me know.

Also, there is an issue, when mining Graft for example, which is a CNv8 coin as well.

Code:

[2018-11-02 16:59:23] Pool graft.ingest.cryptoknight.cc share rejected. (GPU3) Error code: -1 - Wrong algo, use monero7 miner (432/430/2)



When checking the Pool side, it reports hash rate as if 3 cards are mining, not 4. On CNv7, i have used XMR-Stak to mine Graft with
Code:
monero7
flag, since it seemed that they have the same metadata information.


This looks very strange. We only have one pool connection that is shared by all cards, and the shares we submit are for sure CNv8. I'm guessing the pool might not have updated their error message after the fork? Moreover, in your printout above you have 0.46% rejected shares though, nothing out of the ordinary. I tried the same pool now, no problem for my 550/580/Vega 64 test workstation. In the reported stats every 30 secs, are all four cards hashing ok?




I checked with them, seems like you are correct, they have not changed the error message. The rejected shares are due to crappy card quality, not playing nice with the strap. Another thing that i seem to notice is, XMR-Stak was discarding Invalid shares, but logging them regardless, which were equivalent to Hardware Error (HW). But on this fork, instead of being HW, its a Rejected share. I have used the sgminer-gm-5.5.5, and it was doing HWs, instead of rejected shares. Pretty confusing.

I will be checking for the 30/60s stuff for the API.
member
Activity: 413
Merit: 21
newbie
Activity: 9
Merit: 0
Is nicehash supported?  Huh
member
Activity: 658
Merit: 86
Still same problem on win10 18.5.1 rx470-480 series G4400 4Gb ram.All rigs stable on srb 1.6.8-9

Gah this is annoying. It doesn't feel like the init problem we've been battling though. Do you have all the standard environment vars set when running the miner? Srb typically sets them with "setx" in the start bat file, so they should be persistent if you run srb as well. I mean these:

set GPU_MAX_HEAP_SIZE=100
set GPU_MAX_USE_SYNC_OBJECTS=1
set GPU_SINGLE_ALLOC_PERCENT=100
set GPU_MAX_ALLOC_PERCENT=100
set GPU_MAX_SINGLE_ALLOC_PERCENT=100

We should really include them in our example start bat file, that's a mistake. Last, if you run with something silly like 2+2 for all cards, does it work or not?

To speed up this process, would you be willing to hook up on Discord or Telegram? So much easier when you can ping-pong questions in realtime rather than this thread Smiley.

member
Activity: 658
Merit: 86
Hello.
All RIG with poolin.com connect.

          Team Red Miner version 0.3.6
[2018-11-02 18:59:20] Auto-detected AMD OpenCL platform 1
[2018-11-02 18:59:20] Initializing GPU 0.
[2018-11-02 18:59:23] Pool xmr.ss.poolin.com failed to parse server rpc: {"id":1,"jsonrpc":"2.0","result":{"id":"5c0002df","status":"OK","job":{"job_id":"5bdc826610bd4a5c00000000","blob":"0909e684f2de057f8683e8f3ce79c093d89f2fcbdc525b7c282d246fe2f2bfb89a636891143eb10 00000009fdae2def7822a0c34560b46dc32a0bf43f7fe10e1d31a735342559a8fca96d402","target":"ff0f0000"}}}
[2018-11-02 18:59:25] Initializing GPU 1.
[2018-11-02 18:59:29] Initializing GPU 2.
[2018-11-02 18:59:34] Initializing GPU 3.
[2018-11-02 18:59:39] Initializing GPU 4.
[2018-11-02 18:59:39] Pool xmr.ss.poolin.com failed to parse server rpc: {"id":1,"jsonrpc":"2.0","result":{"id":"650002d2","status":"OK","job":{"job_id":"5bdc827acd46b12f00000000","blob":"0909fa84f2de05a208f79644e6d2eb5fceb8c1759851f0f37eb0ccd58b1ee48648aa7f2d86220e0 00000008e6931dbf8e894a549b4abf37a153fb71c6b20bfc57b055bdd320f2194251b6401","target":"ff0f0000"}}}

Ok, something unexpected with the stratum messages going on here. Todxx will take a look at this when he's available. You'll get an update later today.
newbie
Activity: 2
Merit: 0
Hello.
All RIG with poolin.com connect.

          Team Red Miner version 0.3.6
[2018-11-02 18:59:20] Auto-detected AMD OpenCL platform 1
[2018-11-02 18:59:20] Initializing GPU 0.
[2018-11-02 18:59:23] Pool xmr.ss.poolin.com failed to parse server rpc: {"id":1,"jsonrpc":"2.0","result":{"id":"5c0002df","status":"OK","job":{"job_id":"5bdc826610bd4a5c00000000","blob":"0909e684f2de057f8683e8f3ce79c093d89f2fcbdc525b7c282d246fe2f2bfb89a636891143eb10 00000009fdae2def7822a0c34560b46dc32a0bf43f7fe10e1d31a735342559a8fca96d402","target":"ff0f0000"}}}
[2018-11-02 18:59:25] Initializing GPU 1.
[2018-11-02 18:59:29] Initializing GPU 2.
[2018-11-02 18:59:34] Initializing GPU 3.
[2018-11-02 18:59:39] Initializing GPU 4.
[2018-11-02 18:59:39] Pool xmr.ss.poolin.com failed to parse server rpc: {"id":1,"jsonrpc":"2.0","result":{"id":"650002d2","status":"OK","job":{"job_id":"5bdc827acd46b12f00000000","blob":"0909fa84f2de05a208f79644e6d2eb5fceb8c1759851f0f37eb0ccd58b1ee48648aa7f2d86220e0 00000008e6931dbf8e894a549b4abf37a153fb71c6b20bfc57b055bdd320f2194251b6401","target":"ff0f0000"}}}
member
Activity: 658
Merit: 86

Seems like there are changes on what is transmitted over the API, can you give more information about it?


We haven't changed anything API-related per se, but maybe you're hitting this thing: there is a very confusing design aspect with the sgminer API that we just had to follow to be compatible. The json keys for e.g. avg hashrate last N secs change when you change the period between prints. We did change the default period from 60 secs to 30 secs at some point, so the API keys have changed as well. The proper (and annoying) way to do it is to first send a "config" command, check the reported "Log Interval" value there. That value, in our case "30" for 30 secs, will then be used in the keys for all other messages, for example the "summary" command will return the key ""KHS 30s". Imho it's an idiotic design, but we had to follow it. We have a command line option for changing the period. If there's anything else you're noticing, let me know.

Also, there is an issue, when mining Graft for example, which is a CNv8 coin as well.

Code:

[2018-11-02 16:59:23] Pool graft.ingest.cryptoknight.cc share rejected. (GPU3) Error code: -1 - Wrong algo, use monero7 miner (432/430/2)



When checking the Pool side, it reports hash rate as if 3 cards are mining, not 4. On CNv7, i have used XMR-Stak to mine Graft with
Code:
monero7
flag, since it seemed that they have the same metadata information.


This looks very strange. We only have one pool connection that is shared by all cards, and the shares we submit are for sure CNv8. I'm guessing the pool might not have updated their error message after the fork? Moreover, in your printout above you have 0.46% rejected shares though, nothing out of the ordinary. I tried the same pool now, no problem for my 550/580/Vega 64 test workstation. In the reported stats every 30 secs, are all four cards hashing ok?


jr. member
Activity: 130
Merit: 2
Still same problem on win10 18.5.1 rx470-480 series G4400 4Gb ram.All rigs stable on srb 1.6.8-9
Code:
  Team Red Miner version 0.3.6
[2018-11-02 19:47:02] Initializing GPU 0.
[2018-11-02 19:47:04] Pool xmr-eu1.nanopool.org login succeeded.
[2018-11-02 19:47:04] Pool xmr-eu1.nanopool.org received new job. (job_id: 1796)
[2018-11-02 19:47:04] Pool xmr-eu1.nanopool.org set difficulty to 120001
[2018-11-02 19:47:05] Dev pool connected and ready.
[2018-11-02 19:47:06] Initializing GPU 1.
[2018-11-02 19:47:09] Initializing GPU 2.
[2018-11-02 19:47:11] Initializing GPU 3.
[2018-11-02 19:47:15] Initializing GPU 4.
[2018-11-02 19:47:19] Initializing GPU 5.
[2018-11-02 19:47:22] Initializing GPU 6.
[2018-11-02 19:47:26] Successfully initialized GPU 0: Polaris with 36 CU (PCIe 07:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 1: Polaris with 32 CU (PCIe 05:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 2: Polaris with 36 CU (PCIe 03:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 3: Polaris with 32 CU (PCIe 02:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 4: Polaris with 32 CU (PCIe 01:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 5: Polaris with 32 CU (PCIe 09:00.0) (CN 7+7)
[2018-11-02 19:47:26] Successfully initialized GPU 6: Polaris with 32 CU (PCIe 08:00.0) (CN 7+7)
[2018-11-02 19:47:34] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 2 - cnv8: 249.1 h/s, avg 836.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:47:34] Stats Total - cnv8: 249.1 h/s, avg 836.0 h/s, pool   0.0 h/s
[2018-11-02 19:47:38] Pool xmr-eu1.nanopool.org received new job. (job_id: 1797)
[2018-11-02 19:48:01] Pool xmr-eu1.nanopool.org share accepted. (GPU2) (1/1/0)
[2018-11-02 19:48:04] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Pool xmr-eu1.nanopool.org received new job. (job_id: 1798)
[2018-11-02 19:48:47] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats GPU 2 - cnv8: 1.030kh/s, avg 431.9 h/s, pool 1.483kh/s 1/0
[2018-11-02 19:48:47] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:48:47] Stats Total - cnv8: 1.030kh/s, avg 431.9 h/s, pool 1.483kh/s
[2018-11-02 19:49:13] Pool xmr-eu1.nanopool.org received new job. (job_id: 1799)
[2018-11-02 19:49:17] Stats GPU 0 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 1 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 2 - cnv8: 377.3 h/s, avg 573.5 h/s, pool 1.082kh/s 1/0
[2018-11-02 19:49:17] Stats GPU 3 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 4 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 5 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-11-02 19:49:17] Stats Total - cnv8: 377.3 h/s, avg 573.5 h/s, pool 1.082kh/s
member
Activity: 658
Merit: 86
Any plans to support cryptonight-haven?

We will roll out all variants incl the heavy family in due time. Just need to get to a stable point with the miner first, it’ll be a shitshow with support otherwise Smiley.



Please check my post on the start of this page.

Also, any intentions of implementing Share Discarding for Bad Shares (Invalid ones), instead of submitting them to the Pool?

I’ll reply within an hour, phone only right now, doing short replies only.

sr. member
Activity: 487
Merit: 266
Any plans to support cryptonight-haven?

We will roll out all variants incl the heavy family in due time. Just need to get to a stable point with the miner first, it’ll be a shitshow with support otherwise Smiley.



Cool thanks for the quick reply mate!
jr. member
Activity: 194
Merit: 4
Any plans to support cryptonight-haven?

We will roll out all variants incl the heavy family in due time. Just need to get to a stable point with the miner first, it’ll be a shitshow with support otherwise Smiley.



Please check my post on the start of this page.

Also, any intentions of implementing Share Discarding for Bad Shares (Invalid ones), instead of submitting them to the Pool?
newbie
Activity: 22
Merit: 0
teamredminer v0.3.6 Beta Release
This is an optimized miner for AMD GPUs created by todxx and kerney666.

Features In Development:
  • New Algorithms
  • Temp and Fan Monitoring
  • Pool Failover
  • Colors

NIce job, guys! Waiting for the cn-heavy class and watchdog mechanism also. Wink
member
Activity: 658
Merit: 86
Any plans to support cryptonight-haven?

We will roll out all variants incl the heavy family in due time. Just need to get to a stable point with the miner first, it’ll be a shitshow with support otherwise Smiley.

sr. member
Activity: 487
Merit: 266
Any plans to support cryptonight-haven?
member
Activity: 363
Merit: 16
anybody with hasrates for 470 and / or 570 4GB?
ASUS RX570 Expedition OC (modded Elpida bios) clocked at 1225/1940 yields just under 1kh/s. cn_config 7+7. 8+7 seems to be slower.

You've got to give it a go and see for yourself which config will work best, but the above is a pretty safe bet.

i need advice for buying cards Wink 470 and 570 8GB is harder to get than 4GB
jr. member
Activity: 194
Merit: 4


NOTE: This miner does NOT monitor GPU temperatures.
      It is up to the user to ensure that GPU(s) are functioning within safe power and temperature limits.

API: The miner includes a read-only api based on the sgminer-5.5 API.
Both the json and text formats are supported. For more details, we refer to the sgminer api documentation.



Seems like there are changes on what is transmitted over the API, can you give more information about it?

Also, there is an issue, when mining Graft for example, which is a CNv8 coin as well.

Code:

[2018-11-02 16:59:23] Pool graft.ingest.cryptoknight.cc share rejected. (GPU3) Error code: -1 - Wrong algo, use monero7 miner (432/430/2)



When checking the Pool side, it reports hash rate as if 3 cards are mining, not 4. On CNv7, i have used XMR-Stak to mine Graft with
Code:
monero7
flag, since it seemed that they have the same metadata information.


anybody with hasrates for 470 and / or 570 4GB?

Naturally it’d be better for other forum members to provide their verified hashrates, but fwiw the 470/570 4GBs in our tests often reached the 1000+ h/s mark, many times a tad more. Some were stuck at ~850 h/s for all miners. It depends on your core clk as well as mem clk. Power draw should still be fine with a higher core clk. The configs to use are 7+7 and 8+7. Higher won’t work.

Cheers,
K

ok..so not a big impact on v2 like on heavy (where 8GB is much better)

A 1280/1950 570 Gigabyte does  ~980h/s. Although, the core clock is probably useless, gotta try it lower.



hero member
Activity: 1274
Merit: 556
anybody with hasrates for 470 and / or 570 4GB?
ASUS RX570 Expedition OC (modded Elpida bios) clocked at 1225/1940 yields just under 1kh/s. cn_config 7+7. 8+7 seems to be slower.

You've got to give it a go and see for yourself which config will work best, but the above is a pretty safe bet.
member
Activity: 363
Merit: 16
anybody with hasrates for 470 and / or 570 4GB?

Naturally it’d be better for other forum members to provide their verified hashrates, but fwiw the 470/570 4GBs in our tests often reached the 1000+ h/s mark, many times a tad more. Some were stuck at ~850 h/s for all miners. It depends on your core clk as well as mem clk. Power draw should still be fine with a higher core clk. The configs to use are 7+7 and 8+7. Higher won’t work.

Cheers,
K

ok..so not a big impact on v2 like on heavy (where 8GB is much better)
Jump to: