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

[twotwosix]

hi

no way to mine stellite with? only v8?

there is a bug(for me) :
on a rig i had many rejected on 1 card----->low diff---->pool kick rig.

possible to implement "watchdog"? in this case,reboot the miner ?or automaticly reduce intensity?

thnaks

Hi! We will add all variants, all time has gone to work in stability and small features since release. We kicked things off with v8, it felt like the natural first choice.

Did you run the latest 0.3.7 version? It added cpu verification of shares, so low diff shares shouldn't really be sent to the pool. Many pools have crap implementations themselves though and say low diff when the share really was for a previous job.

Watchdog functionality, as well as temps/fans monitoring, are on the TODO list.

Hope you will add stellitev4 and Haven and low the fee, your miner works great

[ku4eto]

Okay, a bit of information.

The CPU verification works really well now.

Instead of 20-40 shares Rejected for 24hours, there are 0. This is good.

The HW errors implementation is not proper though.
Seems like the HW Errors are not passed to the API.
Check the picture below:



GPU1 and GPU3 have both 1 HW detected (as said by the miner), but the API says 0 for both.

[kerney666]

Okay, a bit of information.

The CPU verification works really well now.

Instead of 20-40 shares Rejected for 24hours, there are 0. This is good.

The HW errors implementation is not proper though.
Seems like the HW Errors are not passed to the API.
Check the picture below:



GPU1 and GPU3 have both 1 HW detected (as said by the miner), but the API says 0 for both.

Yeah you're spot on, we missed wiring things together here. Will address it in the next release. Thank you for pointing it out!

[lebuawu2]

Team Red Miner v0.3.7 released

https://github.com/todxx/teamredminer/releases

Changes in v0.3.7

• Redesigned GPU initialization, should now be less error prone.
• Added clean shutdown to reduce driver/GPU crashes.
• Added staggered GPU start-up to reduce GPU crashes.
• Added CPU verification for CNv8 and associated --no_cpu_check option.
• Fixed crash on pool authentication error.
• Added --pool_broken_rpc work-around option for pools that violate json rpc spec.
• Added option to reorder by PCIe bus numbers.
• Added --list_devices option to show available devices.
• Added changed stats formatting to indicate which numbers are accepted/rejected/hw-error shares.
• Added uptime to stats.

Hopefully this release addresses a lot of the bugs you guys have reported!
As you can see from the change list, we've been pretty busy this week

Feedback for new version 0.3.7 :

1. Tested version 0.3.7 on nanopool can confirm avg pool hash rate reported increase compare to version 0.3.6.
2. What is the option to reorder by PCIe bus numbers?

Thanks.

[vacarosie200]

i have a rig 4*vega . no matter conf i use i allways get 0h/s or rig locked down . i change the psu from silver to platinum and it's all ok now . with silver psu i was 890 915 w at wall , now it's 810 820 w at wall. 1950h/s/vega, core 1448mhz, mem 930mhz . thx for this great miner

[kerney666]

Feedback for new version 0.3.7 :

1. Tested version 0.3.7 on nanopool can confirm avg pool hash rate reported increase compare to version 0.3.6.
2. What is the option to reorder by PCIe bus numbers?

Thanks.

1. Nice, good to confirm!
2. --bus_reorder

Note: if you currently have a --cn_config argument tuned to the opencl ordering, make sure you reorder it to match the new order. I forgot it myself, and my 580 driving two monitors had a rough time with the 16+14 config I use for my Vega 64 .

Typically, first run:

Code:

teamredminer.exe --list_devices --bus_reorder

All available devices will now be listed in bus order. If you have a specified --platform argument, add it as well. You will also see the corresponding opencl/default order in the OpenCL column so you can remap the old config argument.

[lebuawu2]

Feedback for new version 0.3.7 :

1. Tested version 0.3.7 on nanopool can confirm avg pool hash rate reported increase compare to version 0.3.6.
2. What is the option to reorder by PCIe bus numbers?

Thanks.

1. Nice, good to confirm!
2. --bus_reorder

Note: if you currently have a --cn_config argument tuned to the opencl ordering, make sure you reorder it to match the new order. I forgot it myself, and my 580 driving two monitors had a rough time with the 16+14 config I use for my Vega 64 .

Typically, first run:

Code:

teamredminer.exe --list_devices --bus_reorder

All available devices will now be listed in bus order. If you have a specified --platform argument, add it as well. You will also see the corresponding opencl/default order in the OpenCL column so you can remap the old config argument.

Noted, all my card is the same type (Vega 56) in one rig so no need to worry about option --cn_config.

[fenomenyaa]

Team Red Miner v0.3.7 released

https://github.com/todxx/teamredminer/releases

Changes in v0.3.7

• Redesigned GPU initialization, should now be less error prone.
• Added clean shutdown to reduce driver/GPU crashes.
• Added staggered GPU start-up to reduce GPU crashes.
• Added CPU verification for CNv8 and associated --no_cpu_check option.
• Fixed crash on pool authentication error.
• Added --pool_broken_rpc work-around option for pools that violate json rpc spec.
• Added option to reorder by PCIe bus numbers.
• Added --list_devices option to show available devices.
• Added changed stats formatting to indicate which numbers are accepted/rejected/hw-error shares.
• Added uptime to stats.

Hopefully this release addresses a lot of the bugs you guys have reported!
As you can see from the change list, we've been pretty busy this week

At last it's working on polaris.İnit problem or i don't what was it gone. power cons. -%8-10 ,hash gain hynix -%1-2(980-985h) samsung +%4-5(1025-1045h) elpida  +%3-4 (990-1020h)custom straps,strange decrase on hynix mems..Anyway Good job dev..

[arierep60]

Guys please fix this:
If my rig have more than 10 gpu I don't get the gpu information like I had in version 0.3.1  

Here is a Rig with 9 GPU, everything looks fine

https://i.imgur.com/jXLtzbt.png



And here is a Rig with 13 GPU

https://i.imgur.com/HnDtGrC.png

I get no GPU info and 3 gpus appear black squares.
Could you fix this please?
Thank you

[kerney666]

Guys please fix this:
If my rig have more than 10 gpu I don't get the gpu information like I had in version 0.3.1  

Here is a Rig with 9 GPU, everything looks fine





And here is a Rig with 13 GPU



I get no GPU info and 3 gpus appear black squares.
Could you fix this please?
Thank you

Hi! Hmm, I'm guessing you have some externally provided HiveOS integration for tdxminer? Since we've changed the output, maybe some log/output parsing is broken now? Do you remember how you set things up way back when for 0.3.1?

[peterboy1]

i encountered a problem today. my pool emailed me that one of my rig isnt working. so after an hour, i checked it. its hashing at 0 for the whole hour.

upon backreading the console, i saw "pool x.x.x.x was closed due to an error", then the hash became 0 and never attempted to reconnect.

whats up?

[todxx]

i encountered a problem today. my pool emailed me that one of my rig isnt working. so after an hour, i checked it. its hashing at 0 for the whole hour.

upon backreading the console, i saw "pool x.x.x.x was closed due to an error", then the hash became 0 and never attempted to reconnect.

whats up?

Well that's not what it's supposed to do.  It should continue to attempt to reconnect to the pool until it succeeds.
So after this error, the miner did not attempt to connect to the pool at all?  Were there any messages printed about the pool after that point?

[peterboy1]

i encountered a problem today. my pool emailed me that one of my rig isnt working. so after an hour, i checked it. its hashing at 0 for the whole hour.

upon backreading the console, i saw "pool x.x.x.x was closed due to an error", then the hash became 0 and never attempted to reconnect.

whats up?

Well that's not what it's supposed to do.  It should continue to attempt to reconnect to the pool until it succeeds.
So after this error, the miner did not attempt to connect to the pool at all?  Were there any messages printed about the pool after that point?

nothing after that. just the regular hashes print, which shows my current hashrate at that time 0.

oh, if this will help, im using nicehash.

[todxx]

i encountered a problem today. my pool emailed me that one of my rig isnt working. so after an hour, i checked it. its hashing at 0 for the whole hour.

upon backreading the console, i saw "pool x.x.x.x was closed due to an error", then the hash became 0 and never attempted to reconnect.

whats up?

Well that's not what it's supposed to do.  It should continue to attempt to reconnect to the pool until it succeeds.
So after this error, the miner did not attempt to connect to the pool at all?  Were there any messages printed about the pool after that point?

nothing after that. just the regular hashes print, which shows my current hashrate at that time 0.

oh, if this will help, im using nicehash.

The pool used shouldn't make a difference, but I also don't know why this would be happening either.  I'll run against nicehash and see if I can get one of my rigs into the same situation.

[arierep60]

Guys please fix this:
If my rig have more than 10 gpu I don't get the gpu information like I had in version 0.3.1  

Here is a Rig with 9 GPU, everything looks fine

https://i.imgur.com/jXLtzbt.png



And here is a Rig with 13 GPU

https://i.imgur.com/HnDtGrC.png

I get no GPU info and 3 gpus appear black squares.
Could you fix this please?
Thank you

Hi! Hmm, I'm guessing you have some externally provided HiveOS integration for tdxminer? Since we've changed the output, maybe some log/output parsing is broken now? Do you remember how you set things up way back when for 0.3.1?

I don't know, a friend helped me, but he have the same problem :/

My FS on hive:

https://i.imgur.com/lJxYJIu.png

From 0.3.1 version to 0.3.7 I just did the update on rig console
what can I do to fix this?

[peterboy1]

btw, can you add ping time next? thanks

[kerney666]

btw, can you add ping time next? thanks

We have the time in ms for accepted/rejected shares on the todo list, good enough?

[tvukoman]

what method are you guys using to have a fixed core clock ?
i set it up for let's say 1400mhz for vega56 using overdriventool but when watching it with HWiNFO is not the same it's about 1350Mhz
any hint appreciated

from yesterday I experience same problem with Vega 56 / 64 cards.

[kerney666]

what method are you guys using to have a fixed core clock ?
i set it up for let's say 1400mhz for vega56 using overdriventool but when watching it with HWiNFO is not the same it's about 1350Mhz
any hint appreciated

from yesterday I experience same problem with Vega 56 / 64 cards.

Have you tried disabling all lower p-states in OverdriveNTool, i.e. click the little text "P2", "P3" etc left of the MHz column so they are greyed out? Only using the highest state has helped me sometimes to force the driver to use the specified clocks.

[tvukoman]

what method are you guys using to have a fixed core clock ?
i set it up for let's say 1400mhz for vega56 using overdriventool but when watching it with HWiNFO is not the same it's about 1350Mhz
any hint appreciated

from yesterday I experience same problem with Vega 56 / 64 cards.

Have you tried disabling all lower p-states in OverdriveNTool, i.e. click the little text "P2", "P3" etc left of the MHz column so they are greyed out? Only using the highest state has helped me sometimes to force the driver to use the specified clocks.

Yes kerney, that is my standard settings in OvedriveNtool.

Just did some more test and found, when applying overdrive and look in the HWiNFO64 i see that GPUP7 clocks is set on  higher values of set in overdrive.ini ?
And when i start miner values go down?
Down in profiles of ovedrivetool.ini i added actual clock values read by HWiNFO before and after start miner:

Run_OverdriveNTool.bat (OverdriveNTool.exe -r1 -r2 -r3 -r4 -p1Sapphire -p2Nitro_RX570 -p3Asus_Vega64 -p4Gigabyte)
[General]
ShowBusNumber=1
ShowPnpString=0
ShowAdapterIndex=0
ShowFriendlyName=0
ShowRegistryKey=1
MainWindowLeft=984
MainWindowTop=244

[Profile_0]
Name=Sapphire
GPU_P0=852;900;0
GPU_P1=991;900;0
GPU_P2=1084;900;0
GPU_P3=1138;900;0
GPU_P4=1150;900;0
GPU_P5=1202;900;0
GPU_P6=1212;905;0    before start miner        after start miner
GPU_P7=1408;955      1437;955            1378 and 1381 (changeing)
Mem_P0=167;900;0
Mem_P1=500;900;0
Mem_P2=800;900;0
Mem_P3=1088;945
Fan_Min=3500
Fan_Max=4900
Fan_Target=75
Fan_Acoustic=2400
Power_Temp=85
Power_Target=0

[Profile_1]
Name=Nitro_RX570
GPU_P0=300;750;0
GPU_P1=588;765;0
GPU_P2=952;943;0
GPU_P3=1041;1012;0
GPU_P4=1106;1075;0
GPU_P5=1168;1143;0
GPU_P6=1209;1150;0
GPU_P7=1170;850
Mem_P0=300;750;0
Mem_P1=1000;800;0
Mem_P2=1970;900
Fan_Min=576
Fan_Max=2150
Fan_Target=50
Fan_Acoustic=1340
Power_Temp=85
Power_Target=0

[Profile_2]
Name=Asus_Vega64
GPU_P0=852;900;0
GPU_P1=991;900;0
GPU_P2=1084;900;0
GPU_P3=1138;900;0
GPU_P4=1150;900;0
GPU_P5=1202;900;0
GPU_P6=1212;905;0
GPU_P7=1490;930             1535;930        1463 and 1466 and 1467 (changeing)
Mem_P0=167;900;0
Mem_P1=500;900;0
Mem_P2=800;900;0
Mem_P3=1100;910
Fan_Min=2300
Fan_Max=3500
Fan_Target=50
Fan_Acoustic=1600
Power_Temp=85
Power_Target=0

[Profile_3]
Name=Gigabyte
GPU_P0=852;900;0
GPU_P1=991;900;0
GPU_P2=1084;900;0
GPU_P3=1138;900;0
GPU_P4=1150;900;0
GPU_P5=1202;900;0
GPU_P6=1212;905;0
GPU_P7=1408;950                1444;950        1381 and 1382 and 1385 (changeing)         
Mem_P0=167;900;0
Mem_P1=500;900;0
Mem_P2=800;900;0
Mem_P3=1070;950
Fan_Min=3350
Fan_Max=4900
Fan_Target=75
Fan_Acoustic=2400
Power_Temp=85
Power_Target=0