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

kerney666

member

Activity: 658

Merit: 86

Quote from: kamisama233 on November 19, 2018, 11:40:27 AM

Quote from: kerney666 on November 18, 2018, 06:09:36 PM

Quote from: coke15 on November 18, 2018, 05:08:31 PM

hi
i have same,when i boot the first lauch does not start mining.i must kill the miner and start new one.

i was in 18.3.4,i updated to 18.6.1 to see...

So, @coke15 and @issie81, when you see a problematic gpu not starting to hash properly, do you see any error message from the initialization process? Or do you see a line with "Successfully initialized ..." for the gpu, but then it still doesn't start hashing ok?

dear designer,i do not know where to quote, so quote here, sorry for doing this. The problem is I found a bug: there are some cards(usually one card on my 6 cards rig) hashrate drop a lot, see the picture i upload, form 500+ down to 360+

it can be several hours or days to happen, api monitor see these changes, when i login to my rigs to see the running window, I use mstsc, then without any operation, the card's hashrate recover to normal 500+(sometime it can not recover), can you fix this bug, thanks

Hi! I don’t think I can help with this specific issue, it sounds more like a rig setup issue. You see the hashrate drop, and when you login remotely to the rig it recovers automatically, without you doing anything else like restarting the miner, resetting clocks etc? Have you checked all power settings, screen lock/screen saver etc? Do you see any pattern at all, or is it completely random?

kamisama233

newbie

Activity: 42

Merit: 0

Quote from: kerney666 on November 18, 2018, 06:09:36 PM

Quote from: coke15 on November 18, 2018, 05:08:31 PM

hi
i have same,when i boot the first lauch does not start mining.i must kill the miner and start new one.

i was in 18.3.4,i updated to 18.6.1 to see...

So, @coke15 and @issie81, when you see a problematic gpu not starting to hash properly, do you see any error message from the initialization process? Or do you see a line with "Successfully initialized ..." for the gpu, but then it still doesn't start hashing ok?

dear designer,i do not know where to quote, so quote here, sorry for doing this. The problem is I found a bug: there are some cards(usually one card on my 6 cards rig) hashrate drop a lot, see the picture i upload, form 500+ down to 360+

https://s1.ax1x.com/2018/11/20/Fp0RxA.md.png

it can be several hours or days to happen, api monitor see these changes, when i login to my rigs to see the running window, I use mstsc, then without any operation, the card's hashrate recover to normal 500+(sometime it can not recover), can you fix this bug, thanks

pbfarmer

member

Activity: 340

Merit: 29

Quote from: Mashy81 on November 17, 2018, 10:30:24 PM

Quote from: ElvinCh on November 16, 2018, 01:57:48 PM

Hello,
first I want to thank you for your hard work, you have done this very good software.
A few days ago I transferred a lot of my mining rings and I am very pleased with the results so far.
I have difficulty and I would like advice on how to achieve a better results with Saphire RX580 8GB Hynix.
What I have done so far:
1. I did tests with several types of BIOS: custom straps for Hynix whit nice result in ETH, one click BIOS from SRBPolarisV3.5 and PolarisBiosEditor1.6.7
2. I have used configurations 8+8, 8+7, 7+7, 15+15, 16+14
3. My settings are: core 1250/900mV and memory 2250/920mV with no hardware errors

In all cases my best results are 900H/s. Embarrassed

Thanks in advance!

Try a trick of mine it works on all my rx570/580 and they are above 1khs.
Once miner starts reset the perimeters on your card. Then just change core clock as high as you can vo stable and as low voltage as you can. Dont even bother with memory clock.

I have found changing memory clock does jack shit. I leave it at stock 1750 and lower voltage thats it.
All my rx570/580 get 1050-1100 hashes with stock memory clock. And between 1280-1340 core.

Vega is a different story though.

Core clock and voltage can be updated live (while GPU is under load.) Mem clock cannot. This is why changing your mem clock doesn't do anything for you, because you're not actually changing it - check the actual clock in HWInfo64. Despite TRM having placed increased importance on core speeds, mem clock is extremely important for CN mining - more so than core, when comparing clock-for-clock increases and what they do for hashrate. The problem is that mem clock increases are more tricky, due to dependence on timings, controller speed/voltages, etc. I have found ideal mem clocks for 580s to range between 2000 and 2250+ depending on mem mfg (and of course which straps you use.)

As for your 'trick', it's addressing the fact that for some reason, power state settings are sometimes not fully honored when load is first applied, but if those same settings are reapplied under load, they stick. This method can be usefule for initial tuning, but once you find the proper clock/voltage values, simply write them into a PPT, and it will accomplish the same thing.

dragonmike

hero member

Activity: 1274

Merit: 556

Quote from: Mashy81 on November 17, 2018, 10:30:24 PM

Try a trick of mine it works on all my rx570/580 and they are above 1khs.
Once miner starts reset the perimeters on your card. Then just change core clock as high as you can vo stable and as low voltage as you can. Dont even bother with memory clock.

I have found changing memory clock does jack shit. I leave it at stock 1750 and lower voltage thats it.
All my rx570/580 get 1050-1100 hashes with stock memory clock. And between 1280-1340 core.

Vega is a different story though.

What do you mean by "reset the perimeters" on the cards?
And do you then apply new clocks while the miner is on?
Do you also increase power limit to allow for the higher clocks? Does it have a noticeable impact on power consumption?

seefatlow

jr. member

Activity: 80

Merit: 1

Quote from: Mashy81 on November 17, 2018, 10:30:24 PM

Quote from: ElvinCh on November 16, 2018, 01:57:48 PM

Hello,
first I want to thank you for your hard work, you have done this very good software.
A few days ago I transferred a lot of my mining rings and I am very pleased with the results so far.
I have difficulty and I would like advice on how to achieve a better results with Saphire RX580 8GB Hynix.
What I have done so far:
1. I did tests with several types of BIOS: custom straps for Hynix whit nice result in ETH, one click BIOS from SRBPolarisV3.5 and PolarisBiosEditor1.6.7
2. I have used configurations 8+8, 8+7, 7+7, 15+15, 16+14
3. My settings are: core 1250/900mV and memory 2250/920mV with no hardware errors

In all cases my best results are 900H/s. Embarrassed

Thanks in advance!

Try a trick of mine it works on all my rx570/580 and they are above 1khs.
Once miner starts reset the perimeters on your card. Then just change core clock as high as you can vo stable and as low voltage as you can. Dont even bother with memory clock.

I have found changing memory clock does jack shit. I leave it at stock 1750 and lower voltage thats it.
All my rx570/580 get 1050-1100 hashes with stock memory clock. And between 1280-1340 core.

Vega is a different story though.

@Mashy81 What does this do to the power consumption? Does it go up appreciably?

vacarosie200

newbie

Activity: 45

Merit: 0

Quote from: issie81 on November 19, 2018, 04:30:41 AM

Quote from: kerney666 on November 18, 2018, 06:09:36 PM

Quote from: coke15 on November 18, 2018, 05:08:31 PM

hi
i have same,when i boot the first lauch does not start mining.i must kill the miner and start new one.

i was in 18.3.4,i updated to 18.6.1 to see...

So, @coke15 and @issie81, when you see a problematic gpu not starting to hash properly, do you see any error message from the initialization process? Or do you see a line with "Successfully initialized ..." for the gpu, but then it still doesn't start hashing ok?

All succesfull it starts mining for hours (sometimes longer) goes ok all of sudden 1 GPU drops others hashing at full speeds, after restart miner starts hashing back rinse and repeat..

Try low the core clock or mem clock 5 mhz steep , it wil hash 24/24 7/7 when you get the right OC values

issie81

hero member

Activity: 760

Merit: 500

CryptoZilla

Quote from: kerney666 on November 18, 2018, 06:09:36 PM

Quote from: coke15 on November 18, 2018, 05:08:31 PM

hi
i have same,when i boot the first lauch does not start mining.i must kill the miner and start new one.

i was in 18.3.4,i updated to 18.6.1 to see...

So, @coke15 and @issie81, when you see a problematic gpu not starting to hash properly, do you see any error message from the initialization process? Or do you see a line with "Successfully initialized ..." for the gpu, but then it still doesn't start hashing ok?

All succesfull it starts mining for hours (sometimes longer) goes ok all of sudden 1 GPU drops others hashing at full speeds, after restart miner starts hashing back rinse and repeat..

kerney666

member

Activity: 658

Merit: 86

Quote from: coke15 on November 18, 2018, 05:08:31 PM

hi
i have same,when i boot the first lauch does not start mining.i must kill the miner and start new one.

i was in 18.3.4,i updated to 18.6.1 to see...

So, @coke15 and @issie81, when you see a problematic gpu not starting to hash properly, do you see any error message from the initialization process? Or do you see a line with "Successfully initialized ..." for the gpu, but then it still doesn't start hashing ok?

kerney666

member

Activity: 658

Merit: 86

Quote from: issie81 on November 18, 2018, 12:02:53 PM

i sometimes miss a Vega 56 when mining a rig, i have like 15 rigs all packed with 4x Vega 56 sometimes 1 gives 0 hashrate, restarting miner fixes the issue, is this know sir Kerney666

It is sort of known, but difficult to say if it's the same issue, there have been few more Windows reports now. Hoping the next update will solve all these issues, but who knows. We'll also have a watchdog in the next release that would catch the zero hash issue and trigger the user's restart script.

coke15

member

Activity: 176

Merit: 10

hi
i have same,when i boot the first lauch does not start mining.i must kill the miner and start new one.

i was in 18.3.4,i updated to 18.6.1 to see...

issie81

hero member

Activity: 760

Merit: 500

CryptoZilla

i sometimes miss a Vega 56 when mining a rig, i have like 15 rigs all packed with 4x Vega 56 sometimes 1 gives 0 hashrate, restarting miner fixes the issue, is this know sir Kerney666

kerney666

member

Activity: 658

Merit: 86

Quote from: Turcy086 on November 18, 2018, 09:22:49 AM

Quote from: kerney666 on November 18, 2018, 08:46:56 AM

Quote from: Turcy086 on November 18, 2018, 06:54:59 AM

My 56 vegas hit 2000H on CV8
But the vega64s hashing 2000 too. I triey many combo 16+14, 16-14 etc
Anybody has a solution?

Hi! It’s surprising, 64s are usually very simple and reliable with this miner. What brands of 64s do you use and what clocks are you running them at?

1420/920
1100/910

What do you get with 15+15? Also, if your core clk is bumped to maybe 1500, do you see an increase in hashrate or not?

Turcy086

newbie

Activity: 5

Merit: 0

Quote from: kerney666 on November 18, 2018, 08:46:56 AM

Quote from: Turcy086 on November 18, 2018, 06:54:59 AM

My 56 vegas hit 2000H on CV8
But the vega64s hashing 2000 too. I triey many combo 16+14, 16-14 etc
Anybody has a solution?

Hi! It’s surprising, 64s are usually very simple and reliable with this miner. What brands of 64s do you use and what clocks are you running them at?

1420/920
1100/910

kerney666

member

Activity: 658

Merit: 86

Quote from: Turcy086 on November 18, 2018, 06:54:59 AM

My 56 vegas hit 2000H on CV8
But the vega64s hashing 2000 too. I triey many combo 16+14, 16-14 etc
Anybody has a solution?

Hi! It’s surprising, 64s are usually very simple and reliable with this miner. What brands of 64s do you use and what clocks are you running them at?

dragonmike

hero member

Activity: 1274

Merit: 556

Howdy Todxx and Kerney666! Was wondering how you were getting on with the development of the heavy/haven algos and x16r (if at all)? Can we expect another mind-blowing (and power-saving, wallet-stroking) release from Teamredminer soon? Grin

Let me know if you need me as guinea pig again, I'm kinda getting used to it now (my mineority-hosted FPGA's hashrate is going down more often than Pamela Anderson on Tommy Lee so I've become good at reporting issues)...

ku4eto

jr. member

Activity: 194

Merit: 4

Quote from: kerney666 on November 17, 2018, 07:07:32 PM

Quote from: ku4eto on November 17, 2018, 05:59:58 PM

Having some weird issue.

0.3.7 is far less stable than 0.3.6 when initiating.

Running 7-7 conf on 4 4GB cards.

When initiating the miner, one of the GPUs will have a thread failing and producing tons of HWs.

For some reason, seems to happen more often on XMR. When starting to mine graft, it does not appear so often.

WHen launching it on 0.3.6, no issues.

Yeah, with 0.3.7 we solved a lot of init issues, but a few weird new ones appeared as well. Are you under Linux or Windows? All known bugs right now are actually driver bugs. One example is the win driver that allocates the same mem space for two kernels in some multiple Polaris gpu settings. We triggered it when solving an earlier bug. We should hopefully solve it in the next version by addressing some code sizes.

The bug you’re describing sounds more like a Linux driver bug we’ve seen though. On every fourth restart of the miner, one command queue will go nuts and just fail running the kernels, but there is no error returned from the opencl api. On the next restart, all is fine again. Three more restarts and the same thing happens. Haven’t seen this on win though, so curious what os you’re running...

I am actually on Windows 10, 1607, with 18.2.1 Drivers.

Mashy81

jr. member

Activity: 225

Merit: 1

Quote from: ElvinCh on November 16, 2018, 01:57:48 PM

Hello,
first I want to thank you for your hard work, you have done this very good software.
A few days ago I transferred a lot of my mining rings and I am very pleased with the results so far.
I have difficulty and I would like advice on how to achieve a better results with Saphire RX580 8GB Hynix.
What I have done so far:
1. I did tests with several types of BIOS: custom straps for Hynix whit nice result in ETH, one click BIOS from SRBPolarisV3.5 and PolarisBiosEditor1.6.7
2. I have used configurations 8+8, 8+7, 7+7, 15+15, 16+14
3. My settings are: core 1250/900mV and memory 2250/920mV with no hardware errors

In all cases my best results are 900H/s. Embarrassed

Thanks in advance!

Try a trick of mine it works on all my rx570/580 and they are above 1khs.
Once miner starts reset the perimeters on your card. Then just change core clock as high as you can vo stable and as low voltage as you can. Dont even bother with memory clock.

I have found changing memory clock does jack shit. I leave it at stock 1750 and lower voltage thats it.
All my rx570/580 get 1050-1100 hashes with stock memory clock. And between 1280-1340 core.

Vega is a different story though.

peterboy1

newbie

Activity: 168

Merit: 0

Quote from: kerney666 on November 17, 2018, 07:07:32 PM

Quote from: ku4eto on November 17, 2018, 05:59:58 PM

Having some weird issue.

0.3.7 is far less stable than 0.3.6 when initiating.

Running 7-7 conf on 4 4GB cards.

When initiating the miner, one of the GPUs will have a thread failing and producing tons of HWs.

For some reason, seems to happen more often on XMR. When starting to mine graft, it does not appear so often.

WHen launching it on 0.3.6, no issues.

Yeah, with 0.3.7 we solved a lot of init issues, but a few weird new ones appeared as well. Are you under Linux or Windows? All known bugs right now are actually driver bugs. One example is the win driver that allocates the same mem space for two kernels in some multiple Polaris gpu settings. We triggered it when solving an earlier bug. We should hopefully solve it in the next version by addressing some code sizes.

The bug you’re describing sounds more like a Linux driver bug we’ve seen though. On every fourth restart of the miner, one command queue will go nuts and just fail running the kernels, but there is no error returned from the opencl api. On the next restart, all is fine again. Three more restarts and the same thing happens. Haven’t seen this on win though, so curious what os you’re running...

we have same symptoms, mine is windows.

kerney666

member

Activity: 658

Merit: 86

Quote from: ku4eto on November 17, 2018, 05:59:58 PM

Having some weird issue.

0.3.7 is far less stable than 0.3.6 when initiating.

Running 7-7 conf on 4 4GB cards.

When initiating the miner, one of the GPUs will have a thread failing and producing tons of HWs.

For some reason, seems to happen more often on XMR. When starting to mine graft, it does not appear so often.

WHen launching it on 0.3.6, no issues.

Yeah, with 0.3.7 we solved a lot of init issues, but a few weird new ones appeared as well. Are you under Linux or Windows? All known bugs right now are actually driver bugs. One example is the win driver that allocates the same mem space for two kernels in some multiple Polaris gpu settings. We triggered it when solving an earlier bug. We should hopefully solve it in the next version by addressing some code sizes.

The bug you’re describing sounds more like a Linux driver bug we’ve seen though. On every fourth restart of the miner, one command queue will go nuts and just fail running the kernels, but there is no error returned from the opencl api. On the next restart, all is fine again. Three more restarts and the same thing happens. Haven’t seen this on win though, so curious what os you’re running...

ku4eto

jr. member

Activity: 194

Merit: 4

Having some weird issue.

0.3.7 is far less stable than 0.3.6 when initiating.

Running 7-7 conf on 4 4GB cards.

When initiating the miner, one of the GPUs will have a thread failing and producing tons of HWs.

For some reason, seems to happen more often on XMR. When starting to mine graft, it does not appear so often.

WHen launching it on 0.3.6, no issues.

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