[ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More

[MegaRipZ]

anyone have any tips on how to make a watchdog.sh script for linux?

reboot.sh -

Code:

#!/bin/bash

echo 1 > /proc/sys/kernel/sysrq
echo u > /proc/sysrq-trigger
sleep 1
echo b > /proc/sysrq-trigger

[ku4eto]

So, my internet died for some reason for 8 hours.

After it came back, and few hours of mining, i see this:

http://i67.tinypic.com/25zs5tj.png

The Miner reported seems OK, the AVG seems OK, considering 8H of 0H/s.

But the pool reported does not seem ok. Why is that?

[tipo70]

Another mistake. Mining time and hashrate of maps is no longer displayed. Only sent jobs and balls are displayed.

[todxx]

So, my internet died for some reason for 8 hours.

After it came back, and few hours of mining, i see this:

http://i67.tinypic.com/25zs5tj.png

The Miner reported seems OK, the AVG seems OK, considering 8H of 0H/s.

But the pool reported does not seem ok. Why is that?

The "pool" hashrate displayed is an average just like the "avg" hashrate displayed is.
Both are averaged over the time the miner has been running, so they should track each other, as they seems to be doing.

[evlo]

what are best possible cnv8 settings for power consumption/performance(hasharete) on rx570 and rx580 samsung K4G80325FB?
777000000000000022CC1C00CEE55C46C0590E1532CD66090060070014051420FA8900A00300000 012123442C3353C19
1300mhz gpu?

[ku4eto]

So, my internet died for some reason for 8 hours.

After it came back, and few hours of mining, i see this:

http://i67.tinypic.com/25zs5tj.png

The Miner reported seems OK, the AVG seems OK, considering 8H of 0H/s.

But the pool reported does not seem ok. Why is that?

The "pool" hashrate displayed is an average just like the "avg" hashrate displayed is.
Both are averaged over the time the miner has been running, so they should track each other, as they seems to be doing.

Oh, thanks for the clarification.

[ramboot]

Hey people! Tell me occasionally pops up such an error

Pool cryptonightv8.eu.nicehash.com share rejected. (GPU3) Error code: 2 - Job not found

OS Windows 10,ati drv 18.3.4 Thank!

[SigiSinatra]

Code:

[2018-12-10 02:53:19] GPU 0 [53C, fan 55%] cnv8: 2.039kh/s, avg 2.041kh/s, pool 1.977kh/s a:1064 r:0 hw:2
[2018-12-10 02:53:19] GPU 1 [49C, fan 57%] cnv8: 3.267kh/s, avg 1.726kh/s, pool 1.609kh/s a:865 r:0 hw:0
[2018-12-10 02:53:19] GPU 2 [51C, fan 56%] cnv8: 2.012kh/s, avg 2.009kh/s, pool 1.919kh/s a:1030 r:0 hw:0
[2018-12-10 02:53:19] GPU 3 [60C, fan 58%] cnv8: 2.015kh/s, avg 2.008kh/s, pool 2.009kh/s a:1079 r:0 hw:0
[2018-12-10 02:53:19] GPU 4 [54C, fan 56%] cnv8: 2.026kh/s, avg 2.018kh/s, pool 1.979kh/s a:1062 r:0 hw:0
[2018-12-10 02:53:19] GPU 5 [49C, fan 56%] cnv8: 2.100kh/s, avg 2.103kh/s, pool 2.008kh/s a:1077 r:0 hw:14
[2018-12-10 02:53:19] Total                cnv8: 13.46kh/s, avg 11.91kh/s, pool 11.50kh/s a:6177 r:0 hw:16

One of my vegas displays 3.267kh/s ?

[kerney666]

Hey people! Tell me occasionally pops up such an error

Pool cryptonightv8.eu.nicehash.com share rejected. (GPU3) Error code: 2 - Job not found

OS Windows 10,ati drv 18.3.4 Thank!

This is Nicehash having switched to a new job and rejecting your share (which belongs to the old job). It will happen more often on Nicehash than when mining coins directly. Not much we can do here, we could potentially implement an abort pattern but you will lose hashrate anyway.

[kerney666]

Code:

[2018-12-10 02:53:19] GPU 0 [53C, fan 55%] cnv8: 2.039kh/s, avg 2.041kh/s, pool 1.977kh/s a:1064 r:0 hw:2
[2018-12-10 02:53:19] GPU 1 [49C, fan 57%] cnv8: 3.267kh/s, avg 1.726kh/s, pool 1.609kh/s a:865 r:0 hw:0
[2018-12-10 02:53:19] GPU 2 [51C, fan 56%] cnv8: 2.012kh/s, avg 2.009kh/s, pool 1.919kh/s a:1030 r:0 hw:0
[2018-12-10 02:53:19] GPU 3 [60C, fan 58%] cnv8: 2.015kh/s, avg 2.008kh/s, pool 2.009kh/s a:1079 r:0 hw:0
[2018-12-10 02:53:19] GPU 4 [54C, fan 56%] cnv8: 2.026kh/s, avg 2.018kh/s, pool 1.979kh/s a:1062 r:0 hw:0
[2018-12-10 02:53:19] GPU 5 [49C, fan 56%] cnv8: 2.100kh/s, avg 2.103kh/s, pool 2.008kh/s a:1077 r:0 hw:14
[2018-12-10 02:53:19] Total                cnv8: 13.46kh/s, avg 11.91kh/s, pool 11.50kh/s a:6177 r:0 hw:16

One of my vegas displays 3.267kh/s ?

Can I ask if you're on Windows or Linux? What's happening is that one of the two threads for that gpu has gone nuts and is not executing the kernels as it should. I can't say why it has happened here though. If Windows, do you have enough swap space? On Linux, we've seen this happening as a pure driver issue, every third time you restart the miner one command queue just fails silently with this behavior.

[pbfarmer]

Code:

[2018-12-10 02:53:19] GPU 0 [53C, fan 55%] cnv8: 2.039kh/s, avg 2.041kh/s, pool 1.977kh/s a:1064 r:0 hw:2
[2018-12-10 02:53:19] GPU 1 [49C, fan 57%] cnv8: 3.267kh/s, avg 1.726kh/s, pool 1.609kh/s a:865 r:0 hw:0
[2018-12-10 02:53:19] GPU 2 [51C, fan 56%] cnv8: 2.012kh/s, avg 2.009kh/s, pool 1.919kh/s a:1030 r:0 hw:0
[2018-12-10 02:53:19] GPU 3 [60C, fan 58%] cnv8: 2.015kh/s, avg 2.008kh/s, pool 2.009kh/s a:1079 r:0 hw:0
[2018-12-10 02:53:19] GPU 4 [54C, fan 56%] cnv8: 2.026kh/s, avg 2.018kh/s, pool 1.979kh/s a:1062 r:0 hw:0
[2018-12-10 02:53:19] GPU 5 [49C, fan 56%] cnv8: 2.100kh/s, avg 2.103kh/s, pool 2.008kh/s a:1077 r:0 hw:14
[2018-12-10 02:53:19] Total                cnv8: 13.46kh/s, avg 11.91kh/s, pool 11.50kh/s a:6177 r:0 hw:16

One of my vegas displays 3.267kh/s ?

Can I ask if you're on Windows or Linux? What's happening is that one of the two threads for that gpu has gone nuts and is not executing the kernels as it should. I can't say why it has happened here though. If Windows, do you have enough swap space? On Linux, we've seen this happening as a pure driver issue, every third time you restart the miner one command queue just fails silently with this behavior.

I’ve seen this quite a few times as well, on Windows.  Seems to just be another failure mode of insufficient voltage for chosen clocks.  And like other failures, it may often only present itself after hours, or even days of stable mining, due to the significant power transients (I assume.)

[ramboot]

Hey people! Tell me occasionally pops up such an error

Pool cryptonightv8.eu.nicehash.com share rejected. (GPU3) Error code: 2 - Job not found

OS Windows 10,ati drv 18.3.4 Thank!

This is Nicehash having switched to a new job and rejecting your share (which belongs to the old job). It will happen more often on Nicehash than when mining coins directly. Not much we can do here, we could potentially implement an abort pattern but you will lose hashrate anyway.

Thank you very much for the detailed response.

[GordoLui]

Just started using this miner over the weekend and its great. It's not very difficult to set up and is pretty stable for the most part. I was using castXMR before this and my result on CNV8 for 3 vega 56 was at around 4800-4900 sol/s with around 600 watts of power. Using TRM I am getting 5600 sol/s with and the same amount of power. This is all without using any soft power tables or any other mods. Testing using soft mods on one system and its gotten me 5700 sol/s with slightly reduce power draw of around 560-570 watts at the wall.

The only downside is that this thing does not run all that hot which normally be seen as great but seeing as i am using these miners to heat the house it does make it a little less convenient in that sense. Running cooler will make them really nice for the summer. Maybe I should just run a warmer algorithm instead and mine different coins for now?

My question for now are concerning the 3 readings you get; CNV8, AVG, Pool. They are almost the same with slight differences but the pool is a bit lower or sometimes higher. Can someone explain whats going on with those reading?

[kerney666]

Just started using this miner over the weekend and its great. It's not very difficult to set up and is pretty stable for the most part. I was using castXMR before this and my result on CNV8 for 3 vega 56 was at around 4800-4900 sol/s with around 600 watts of power. Using TRM I am getting 5600 sol/s with and the same amount of power. This is all without using any soft power tables or any other mods. Testing using soft mods on one system and its gotten me 5700 sol/s with slightly reduce power draw of around 560-570 watts at the wall.

The only downside is that this thing does not run all that hot which normally be seen as great but seeing as i am using these miners to heat the house it does make it a little less convenient in that sense. Running cooler will make them really nice for the summer. Maybe I should just run a warmer algorithm instead and mine different coins for now?

My question for now are concerning the 3 readings you get; CNV8, AVG, Pool. They are almost the same with slight differences but the pool is a bit lower or sometimes higher. Can someone explain whats going on with those reading?

Hi! Haha, hard to please everyone I guess . Well, if you really want to push more energy/heat, maybe you can find some better algo/miner for the purpose. Or, you can always try to push your Vega 56s a little higher with a higher core clk, maybe get a few extra hashes.

For the readings:

• CNv8: the total miner hashrate, including the dev fee.
• Avg: just the avg miner hashrate over time, smoothens it out a bit.
• Pool: this is your hashrate based on _accepted_ shares. Given enough runtime, it will converge to miner hashrate (CNv8) - 2.5% dev fee - rejected shares - any other downtime.

So, in a perfect world with zero rejected shares/pool issues/network issues, your pool hashrate should be 97.5% of the miner hashrate. However, shit will always happen. Depending on how your pool handle stale shares, it's realistic to assume 1-1.5% rejected shares. Some pools accept them anyway even though they are useless, and it'll show in your earnings anyway.

[scryptr]

TOO MANY REJECTS--

Your explanation makes sense and is mostly true, but I think the code needs to be refined to reduce rejects.  I stopped using TeamRedMiner for anything but my Vega cards.  There is solid improvement on my Vegas, maybe 30%, over XMR-Stak, but the rejects are still there.  My lesser RX series cards do not show real improvement on pool-side statistics.  The rig-side hash rate is higher, but after fees and rejects, pool-side is slightly less.

Smooth out the code please.  I am hoping to build more Vega rigs.  Your miner is good, but it needs some work.

Thanks for the good code, make it better!       --scryptr

[iRonNuke]

TOO MANY REJECTS--

Your explanation makes sense and is mostly true, but I think the code needs to be refined to reduce rejects.  I stopped using TeamRedMiner for anything but my Vega cards.  There is solid improvement on my Vegas, maybe 30%, over XMR-Stak, but the rejects are still there.  My lesser RX series cards do not show real improvement on pool-side statistics.  The rig-side hash rate is higher, but after fees and rejects, pool-side is slightly less.

Smooth out the code please.  I am hoping to build more Vega rigs.  Your miner is good, but it needs some work.

Thanks for the good code, make it better!       --scryptr

You need to consider the lower power usage with TeamRedMiner. Atleast it's quite big difference between for example SRBMiner/XMR-Stak and TeamRedMiner. With TeamRedMiner I'll get around 1100 W with my rig, and with the other miners I gets around 1250 W, big difference! I have a mix of RX 560/570/580 and Vegas in that rig. I also are running a rig with some RX 550/560 and that rig saves only about 10 W.

EDIT: But I can agree with you about rejected shares. When looking right now at my bigger rig, it says 9691 accepted and 253 rejected. Seems very high.

[kerney666]

TOO MANY REJECTS--

Your explanation makes sense and is mostly true, but I think the code needs to be refined to reduce rejects.  I stopped using TeamRedMiner for anything but my Vega cards.  There is solid improvement on my Vegas, maybe 30%, over XMR-Stak, but the rejects are still there.  My lesser RX series cards do not show real improvement on pool-side statistics.  The rig-side hash rate is higher, but after fees and rejects, pool-side is slightly less.

Smooth out the code please.  I am hoping to build more Vega rigs.  Your miner is good, but it needs some work.

Thanks for the good code, make it better!       --scryptr

On which pool are you mining? I've noticed Nanopool is way too strict with shares for new jobs that still are for same blockheight as the previous job. I really really wonder what they do with submitted shares for the previous job that matches the network difficulty...

[kerney666]

TOO MANY REJECTS--

Your explanation makes sense and is mostly true, but I think the code needs to be refined to reduce rejects.  I stopped using TeamRedMiner for anything but my Vega cards.  There is solid improvement on my Vegas, maybe 30%, over XMR-Stak, but the rejects are still there.  My lesser RX series cards do not show real improvement on pool-side statistics.  The rig-side hash rate is higher, but after fees and rejects, pool-side is slightly less.

Smooth out the code please.  I am hoping to build more Vega rigs.  Your miner is good, but it needs some work.

Thanks for the good code, make it better!       --scryptr

You need to consider the lower power usage with TeamRedMiner. Atleast it's quite big difference between for example SRBMiner/XMR-Stak and TeamRedMiner. With TeamRedMiner I'll get around 1100 W with my rig, and with the other miners I gets around 1250 W, big difference! I have a mix of RX 560/570/580 and Vegas in that rig. I also are running a rig with some RX 550/560 and that rig saves only about 10 W.

EDIT: But I can agree with you about rejected shares. When looking right now at my bigger rig, it says 9691 accepted and 253 rejected. Seems very high.

Hm, it is interesting though. I mean, I believe we _always_ submit stale shares rather than discard them, even though we know we just received a new job. This means you'll see them as rejected in TRM but not see them at all in e.g. stak. At the end of the day, the only interesting number is the accepted poolside hashrate, all other numbers can be dependent on different miner implementations and strategies.

For the "true" rejects, they should only be dependent on (1) pool policy for stale shares, (2) miner thread job runtime, (3) any additional overhead/latency in the network/miner.

(1) above has nothing to do with the miner, (2) should be very aligned between TRM and stak. (3) is a little interesting though. We refuse to steal any open source code, so we wrote our CN CPU verification from scratch in plain C code. It is def a lot slower than the AES-NI code in xmr-stak and others and could maybe be bumping the reject rate a little, but it shouldn't really be much.

So SCRYPTR, just curious if you see any difference if you disable the cpu verification with "--no_cpu_check"? I don't know if some pools have a window after sending out a new job where old shares are still accepted, but after 100ms they are rejected. If that's the case our slower cpu verification could very much be a factor.

[scryptr]

TOO MANY REJECTS--

Your explanation makes sense and is mostly true, but I think the code needs to be refined to reduce rejects.  I stopped using TeamRedMiner for anything but my Vega cards.  There is solid improvement on my Vegas, maybe 30%, over XMR-Stak, but the rejects are still there.  My lesser RX series cards do not show real improvement on pool-side statistics.  The rig-side hash rate is higher, but after fees and rejects, pool-side is slightly less.

Smooth out the code please.  I am hoping to build more Vega rigs.  Your miner is good, but it needs some work.

Thanks for the good code, make it better!       --scryptr

You need to consider the lower power usage with TeamRedMiner. Atleast it's quite big difference between for example SRBMiner/XMR-Stak and TeamRedMiner. With TeamRedMiner I'll get around 1100 W with my rig, and with the other miners I gets around 1250 W, big difference! I have a mix of RX 560/570/580 and Vegas in that rig. I also are running a rig with some RX 550/560 and that rig saves only about 10 W.

EDIT: But I can agree with you about rejected shares. When looking right now at my bigger rig, it says 9691 accepted and 253 rejected. Seems very high.

Hm, it is interesting though. I mean, I believe we _always_ submit stale shares rather than discard them, even though we know we just received a new job. This means you'll see them as rejected in TRM but not see them at all in e.g. stak. At the end of the day, the only interesting number is the accepted poolside hashrate, all other numbers can be dependent on different miner implementations and strategies.

For the "true" rejects, they should only be dependent on (1) pool policy for stale shares, (2) miner thread job runtime, (3) any additional overhead/latency in the network/miner.

(1) above has nothing to do with the miner, (2) should be very aligned between TRM and stak. (3) is a little interesting though. We refuse to steal any open source code, so we wrote our CN CPU verification from scratch in plain C code. It is def a lot slower than the AES-NI code in xmr-stak and others and could maybe be bumping the reject rate a little, but it shouldn't really be much.

So SCRYPTR, just curious if you see any difference if you disable the cpu verification with "--no_cpu_check"? I don't know if some pools have a window after sending out a new job where old shares are still accepted, but after 100ms they are rejected. If that's the case our slower cpu verification could very much be a factor.

THANK YOU FOR THE RESPONSE--

I have not tried the "--no_cpu_check".  I never submit stales, with "--no_submit_stale".  That could be a possible option, but it is not yet implemented in your code.  And, your theory about slow code sounds reasonable.

Right now, my 4xVega box reports about 7,500 accepts with about 225 rejects, a rig-side hash rate of 8.1kH/s, a pool-side hash rate of 7.75kH/s.  The 225/7500 yields a 3% reject rate, and the (8.1-7.75)/8.1 yields about a 4.3% hash loss due to the various reasons you cited.  But the Vegas are outperforming my other RX series cards by far; the lesser cards had more rejects.  And, the Vegas outperform themselves by at least 1/3 compared to their hash rate when mining with XMR-Stak.

So, I wait.  The latest XMR-Stak, 2.7.0, did wonders for my other cards.  My Vegas are doing better on TRM than before on XMR-Stak.

Thanks again!       --scryptr

 

[vmozara]

Guys what is the command to reorder GPUs by BUS ID? Kerney, todxx, This command is not in the readme or first page of topic, only text "Added option to reorder GPU by BUS ID", can you add it to have it in readme?