Author

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

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: 127
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: 361
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: 361
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)
newbie
Activity: 10
Merit: 0
Please tell me how this amount is obtained Pool xmr-eu2.nanopool.org share accepted. (GPU0) (154/151/1) 151 + 1 = 152 but not 154! Or something I do not understand? Undecided

Well, either it was followed immediately by two more output lines with shares found in the same enqueued work so the (global) total counter was already increased with +2 more shares, or we have a bug,  or it's also possible that either the stratum communication with the pool is messed up or the nanopool themselves messed up and never responded for two of your shares. The first counter is incremented when shares are found, the last two when the pool reports back and we know the accepted/rejected status.

Do you see it continuously, i.e. for your GPU0 you're always missing two shares (unless you've restarted already)?

[2018-11-02 13:43:27] Pool xmr-eu2.nanopool.org received new job. (job_id: 1998)
[2018-11-02 13:43:27] Pool xmr-eu2.nanopool.org share rejected. (GPU0) Error code: -1 - Block expired (438/425/9)
[2018-11-02 13:43:39] Pool xmr-eu2.nanopool.org share accepted. (GPU0) (439/426/9)
[2018-11-02 13:43:52] Stats GPU 0 - cnv8: 2.310kh/s, avg 2.340kh/s, pool 2.387kh/s 426/9
[2018-11-02 13:44:22] Stats GPU 0 - cnv8: 2.310kh/s, avg 2.340kh/s, pool 2.383kh/s 426/9
[2018-11-02 13:44:25] Pool xmr-eu2.nanopool.org received new job. (job_id: 1999)
[2018-11-02 13:44:41] Pool xmr-eu2.nanopool.org share accepted. (GPU0) (440/427/9)
[2018-11-02 13:44:52] Stats GPU 0 - cnv8: 2.310kh/s, avg 2.340kh/s, pool 2.385kh/s 427/9
Even when I restarted, these "unrecorded shares" still appear. The total percentage of them is not more than 2.
Jump to: