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

tvukoman

jr. member

Activity: 69

Merit: 5

Quote from: Germini on November 07, 2018, 02:08:34 AM

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

member

Activity: 658

Merit: 86

Quote from: peterboy1 on November 09, 2018, 12:55:15 PM

btw, can you add ping time next? thanks

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

peterboy1

newbie

Activity: 168

Merit: 0

btw, can you add ping time next? thanks

arierep60

newbie

Activity: 50

Merit: 0

Quote from: kerney666 on November 08, 2018, 11:39:18 PM

Quote from: arierep60 on November 08, 2018, 06:59:08 PM

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 Sad

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?

todxx

member

Activity: 176

Merit: 76

Quote from: peterboy1 on November 09, 2018, 07:00:45 AM

Quote from: todxx on November 09, 2018, 06:54:56 AM

Quote from: peterboy1 on November 09, 2018, 04:24:54 AM

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.

peterboy1

newbie

Activity: 168

Merit: 0

Quote from: todxx on November 09, 2018, 06:54:56 AM

Quote from: peterboy1 on November 09, 2018, 04:24:54 AM

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

member

Activity: 176

Merit: 76

Quote from: peterboy1 on November 09, 2018, 04:24:54 AM

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

newbie

Activity: 168

Merit: 0

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?

kerney666

member

Activity: 658

Merit: 86

Quote from: arierep60 on November 08, 2018, 06:59:08 PM

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 Sad

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?

arierep60

newbie

Activity: 50

Merit: 0

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 Sad

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

fenomenyaa

jr. member

Activity: 130

Merit: 2

Quote from: todxx on November 07, 2018, 11:34:58 PM

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..

lebuawu2

jr. member

Activity: 176

Merit: 2

Quote from: kerney666 on November 08, 2018, 05:40:08 PM

Quote from: lebuawu2 on November 08, 2018, 04:55:11 PM

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.

kerney666

member

Activity: 658

Merit: 86

Quote from: lebuawu2 on November 08, 2018, 04:55:11 PM

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.

vacarosie200

newbie

Activity: 45

Merit: 0

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

lebuawu2

jr. member

Activity: 176

Merit: 2

Quote from: todxx on November 07, 2018, 11:34:58 PM

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.

kerney666

member

Activity: 658

Merit: 86

Quote from: ku4eto on November 08, 2018, 02:39:29 PM

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!

ku4eto

jr. member

Activity: 194

Merit: 4

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.

twotwosix

newbie

Activity: 118

Merit: 0

Quote from: kerney666 on November 08, 2018, 01:38:51 PM

Quote from: coke15 on November 08, 2018, 01:16:29 PM

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

kerney666

member

Activity: 658

Merit: 86

Quote from: coke15 on November 08, 2018, 01:16:29 PM

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.

coke15

member

Activity: 176

Merit: 10

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

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