Bitcoin Forum
January 25, 2020, 04:42:39 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 [68] 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 »
  Print  
Author Topic: [ANN] TeamRedMiner 0.6.1 - Ethash/Cryptonight/Chukwa Thread  (Read 96440 times)
Mashy81
Jr. Member
*
Offline Offline

Activity: 223
Merit: 1


View Profile
April 22, 2019, 01:28:37 AM
 #1341

Hello prompt how to include a single-threaded mode, in readme read that it is necessary to use a configuration Y+0, but I tried various combinations (--cn_config=Y+0,L16+16,16+16,16+16,L16+16,L16+16) but the miner gives an error, tell me what I'm doing wrong. As the card which is inserted in X16 irrespective of dispersal and intensity gives out HW errors, I thought can the single-threaded mode will be able to solve my problem.

Just replace Y (intensity) with a value. --cn_config=16+0 for example.
Thanks

Also replace +  with  *  not all card like 16*16. My best value is 16*14
1579970559
Hero Member
*
Offline Offline

Posts: 1579970559

View Profile Personal Message (Offline)

Ignore
1579970559
Reply with quote  #2

1579970559
Report to moderator
1579970559
Hero Member
*
Offline Offline

Posts: 1579970559

View Profile Personal Message (Offline)

Ignore
1579970559
Reply with quote  #2

1579970559
Report to moderator
1579970559
Hero Member
*
Offline Offline

Posts: 1579970559

View Profile Personal Message (Offline)

Ignore
1579970559
Reply with quote  #2

1579970559
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
SamAlackass
Newbie
*
Offline Offline

Activity: 27
Merit: 1


View Profile
April 22, 2019, 03:37:25 AM
 #1342

FYI, I completed an evaluation between win10 driver 18.6.1 vs 19.4.2. Found no hashrate/power draw difference with TRM 0.4.4 miner. Evaluated on CNR algo only.

Still using ODNT? How do you set your fan speeds? IIRC there is no target temp in the beta version.

I tested a few 19.x drivers recently, on a 3x vega 56 rig, TRM 0.4.2 (also CNR only) and came to the same conclusion. Didn't have enough time to play with ODNT, but it felt weird having to spend time tweaking fan speeds. Target temp has been a set and forget kind of thing for me so...      

You can set your target temp in PPT...

Vega (hex short, byteswapped -- e.g. "1c,00" => 0x001c => 0d28):

https://i.imgur.com/8JhCNwRm.png

Polaris (hex char -- e.g. "28" => 0x28 => 0d40):

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

Thank you for that!! It seems to be working! Your posts have always been immensely helpful.

I can't try the beta ODNT right now as I'm currently on old drivers and it's crashing so, am I right to assume the fan speed section can still be disabled in beta?
pbfarmer
Member
**
Offline Offline

Activity: 316
Merit: 24


View Profile
April 22, 2019, 06:02:50 AM
 #1343

FYI, I completed an evaluation between win10 driver 18.6.1 vs 19.4.2. Found no hashrate/power draw difference with TRM 0.4.4 miner. Evaluated on CNR algo only.

Still using ODNT? How do you set your fan speeds? IIRC there is no target temp in the beta version.

I tested a few 19.x drivers recently, on a 3x vega 56 rig, TRM 0.4.2 (also CNR only) and came to the same conclusion. Didn't have enough time to play with ODNT, but it felt weird having to spend time tweaking fan speeds. Target temp has been a set and forget kind of thing for me so...      

You can set your target temp in PPT...

Vega (hex short, byteswapped -- e.g. "1c,00" => 0x001c => 0d28):



Polaris (hex char -- e.g. "28" => 0x28 => 0d40):



Thank you for that!! It seems to be working! Your posts have always been immensely helpful.

I can't try the beta ODNT right now as I'm currently on old drivers and it's crashing so, am I right to assume the fan speed section can still be disabled in beta?

Np - happy to help.  I don't know about disabling, but ODNT just reads the value from PPT, so you shouldnt need to worry about it, unless you want to change it.
Mashy81
Jr. Member
*
Offline Offline

Activity: 223
Merit: 1


View Profile
April 22, 2019, 08:44:24 AM
 #1344

Best I can get efficiency to is 10.7hs per Watt.  Undecided
I might have to go linux..
SamAlackass
Newbie
*
Offline Offline

Activity: 27
Merit: 1


View Profile
April 22, 2019, 10:26:32 AM
 #1345

FYI, I completed an evaluation between win10 driver 18.6.1 vs 19.4.2. Found no hashrate/power draw difference with TRM 0.4.4 miner. Evaluated on CNR algo only.

Still using ODNT? How do you set your fan speeds? IIRC there is no target temp in the beta version.

I tested a few 19.x drivers recently, on a 3x vega 56 rig, TRM 0.4.2 (also CNR only) and came to the same conclusion. Didn't have enough time to play with ODNT, but it felt weird having to spend time tweaking fan speeds. Target temp has been a set and forget kind of thing for me so...      

You can set your target temp in PPT...

Vega (hex short, byteswapped -- e.g. "1c,00" => 0x001c => 0d28):

https://i.imgur.com/8JhCNwRm.png

Polaris (hex char -- e.g. "28" => 0x28 => 0d40):

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

Thank you for that!! It seems to be working! Your posts have always been immensely helpful.

I can't try the beta ODNT right now as I'm currently on old drivers and it's crashing so, am I right to assume the fan speed section can still be disabled in beta?

Np - happy to help.  I don't know about disabling, but ODNT just reads the value from PPT, so you shouldnt need to worry about it, unless you want to change it.

It doesn't seem to be reading it from PPT, I just double checked to make sure. Apparently it just defaults to 75 no matter what value I set in PPT. So unless the fan section can still be disabled in newer ODNT versions, it will just override whatever is set in PPT apparently.
carlosmonaco
Newbie
*
Offline Offline

Activity: 104
Merit: 0


View Profile
April 22, 2019, 10:34:35 AM
 #1346

When I was looking how to decrease consumption I found two things really weird.

One of my rig is reporting a huge diference between reported hashrate and pool hashrate . ( No hw error etc..)
https://imgur.com/a/In6q2S4
There is no error and there is 2 kh/s between pool hashrate and reported hashrate.

The second thing is even weird:

This is my PPT for my Vega 64:
https://imgur.com/a/NTuNGjT

P0->p6 core are disable and P0->P2 mem too  and for the last state I use 875mV but when I check HWinfo when mining voltage is still around 895 mV.

Look like it use the higher voltage of disable state when running.

So I try to change my PPT by using 820mV for all state except the last one for core and mem.
I keep the exact same P7 core and P3 mem but my card is reporting dead almost one min after starting to mine.

Any explanation ?
rednoW
Legendary
*
Offline Offline

Activity: 1386
Merit: 1003


View Profile
April 22, 2019, 10:53:31 AM
 #1347

Are we going to see heavy (heaven) algo support in TeamRed? Current implementation of SRBminer is poor compute-wise optimized and needs high gpu clocks and a lot of power ((
kerney666
Member
**
Offline Offline

Activity: 532
Merit: 84


View Profile
April 22, 2019, 11:18:32 AM
 #1348

FYI, I completed an evaluation between win10 driver 18.6.1 vs 19.4.2. Found no hashrate/power draw difference with TRM 0.4.4 miner. Evaluated on CNR algo only.

Still using ODNT? How do you set your fan speeds? IIRC there is no target temp in the beta version.

I tested a few 19.x drivers recently, on a 3x vega 56 rig, TRM 0.4.2 (also CNR only) and came to the same conclusion. Didn't have enough time to play with ODNT, but it felt weird having to spend time tweaking fan speeds. Target temp has been a set and forget kind of thing for me so...      

You can set your target temp in PPT...

Vega (hex short, byteswapped -- e.g. "1c,00" => 0x001c => 0d28):



Polaris (hex char -- e.g. "28" => 0x28 => 0d40):



Thank you for that!! It seems to be working! Your posts have always been immensely helpful.

I can't try the beta ODNT right now as I'm currently on old drivers and it's crashing so, am I right to assume the fan speed section can still be disabled in beta?

Np - happy to help.  I don't know about disabling, but ODNT just reads the value from PPT, so you shouldnt need to worry about it, unless you want to change it.

It doesn't seem to be reading it from PPT, I just double checked to make sure. Apparently it just defaults to 75 no matter what value I set in PPT. So unless the fan section can still be disabled in newer ODNT versions, it will just override whatever is set in PPT apparently.

Since later drivers (>= 19.2.x or so) are using a different approach with a fan curve instead of a single target temp, I'm guessing they don't care about the old classic target temp in the PPT. It's not by random chance that the target temp is missing in the ODNT beta that supports these drivers. The implementation of the fan curve is also f-ing horrible, there is no interpolation with smooth fan rpm increase, it's like they only switch hard between two adjacent points on the curve. This is for 19.2.2 though, might have improved in later versions?
kerney666
Member
**
Offline Offline

Activity: 532
Merit: 84


View Profile
April 22, 2019, 11:21:49 AM
 #1349

Hello prompt how to include a single-threaded mode, in readme read that it is necessary to use a configuration Y+0, but I tried various combinations (--cn_config=Y+0,L16+16,16+16,16+16,L16+16,L16+16) but the miner gives an error, tell me what I'm doing wrong. As the card which is inserted in X16 irrespective of dispersal and intensity gives out HW errors, I thought can the single-threaded mode will be able to solve my problem.

Just replace Y (intensity) with a value. --cn_config=16+0 for example.
Thanks

Also replace +  with  *  not all card like 16*16. My best value is 16*14

16+16 is always a bad idea, it would use 8GB for pads. I hate that the drivers allow it, I'm guessing they are actually spilling using host-side mem mapped over PCIe,
kerney666
Member
**
Offline Offline

Activity: 532
Merit: 84


View Profile
April 22, 2019, 11:49:18 AM
 #1350

When I was looking how to decrease consumption I found two things really weird.

One of my rig is reporting a huge diference between reported hashrate and pool hashrate . ( No hw error etc..)

There is no error and there is 2 kh/s between pool hashrate and reported hashrate.

Miner vs poolside testing is a b*tch, and I dedicated the last section of the CN_MAX_YOUR_VEGA.txt guide in the 0.4.4 release to it. That said, your numbers are way off, this should happen in <= 0.07% of all cases _if you were running at a static diff_. Since you aren't, it's really difficult to reason about if this is a "normal outlier" that happens every 100th run, or that it more or less proves that something clearly is off.

Drilling deeper and looking at each gpu, two of your cards look a little fishy at 1480 h/s poolside, but we have way too little data to assert anything on a per-gpu basis. So, please run a xmrig-proxy test as decribed in the guide for e.g. 50k shares total and you should have the data you need - it might be that those two cards are not doing great at the current clocks and/or timing mods, and it should be clearly visible with that higher amount of shares. We're doing tons and tons of testing ourselves to make sure we hit the poolside hashrate, I'd love to get more user data here, but it must be from runs that I know I can trust from a statistical standpoint.

The second thing is even weird:

This is my PPT for my Vega 64:


P0->p6 core are disable and P0->P2 mem too  and for the last state I use 875mV but when I check HWinfo when mining voltage is still around 895 mV.

Look like it use the higher voltage of disable state when running.

So I try to change my PPT by using 820mV for all state except the last one for core and mem.
I keep the exact same P7 core and P3 mem but my card is reporting dead almost one min after starting to mine.

Any explanation ?

Newer drivers often seem to lock P7 core+P3 mem during load to not be too aggressive with switching p-states.

For the PPT itself, this is an artform. Don't be fooled by the view in ODNT. The only thing that exists is a single vdd lookup table which is _shared_ by core and mem states. ODNT fools you into believing that you can separate voltage settings for e.g. core P4 from mem P3, which isn't true unless you do some serious PPT tweaking. I'm not 100% it's possible even then.

To simplify your tests, I'd either (1) use the same target voltage for ALL core and mem states in your PPT or (2) make sure all core and mem states have increasing voltage levels in respective series and also that core P4 voltage == mem P3 voltage and that it matches your target.

I'm not 100% sure what happens in your tests. Maybe mem P3 is rather grabbed from core P4, so in your first test you get 900 mV (~= 895 mV), and in your second test you get 820 mV which is way too low to handle sustained pressure?

kerney666
Member
**
Offline Offline

Activity: 532
Merit: 84


View Profile
April 22, 2019, 12:43:26 PM
 #1351

Are we going to see heavy (heaven) algo support in TeamRed? Current implementation of SRBminer is poor compute-wise optimized and needs high gpu clocks and a lot of power ((

Yeah, should have been done already. I'm away for Easter, then I'll hit CNv7 Lite, then probably the 4MB variants that still are active.
akvilon888
Newbie
*
Offline Offline

Activity: 19
Merit: 0


View Profile
April 22, 2019, 01:03:29 PM
 #1352

hi, what command i have to use to restart miner if some gpu failed ?
MaxHa$h
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
April 22, 2019, 02:31:45 PM
 #1353

hi, what command i have to use to restart miner if some gpu failed ?

create a batch file and name it

you can use this in the file

SHUTDOWN -r -t 10


watchdog="filename"
carlosmonaco
Newbie
*
Offline Offline

Activity: 104
Merit: 0


View Profile
April 22, 2019, 03:07:20 PM
 #1354

When I was looking how to decrease consumption I found two things really weird.

One of my rig is reporting a huge diference between reported hashrate and pool hashrate . ( No hw error etc..)
https://imgur.com/a/In6q2S4
There is no error and there is 2 kh/s between pool hashrate and reported hashrate.

Miner vs poolside testing is a b*tch, and I dedicated the last section of the CN_MAX_YOUR_VEGA.txt guide in the 0.4.4 release to it. That said, your numbers are way off, this should happen in <= 0.07% of all cases _if you were running at a static diff_. Since you aren't, it's really difficult to reason about if this is a "normal outlier" that happens every 100th run, or that it more or less proves that something clearly is off.

Drilling deeper and looking at each gpu, two of your cards look a little fishy at 1480 h/s poolside, but we have way too little data to assert anything on a per-gpu basis. So, please run a xmrig-proxy test as decribed in the guide for e.g. 50k shares total and you should have the data you need - it might be that those two cards are not doing great at the current clocks and/or timing mods, and it should be clearly visible with that higher amount of shares. We're doing tons and tons of testing ourselves to make sure we hit the poolside hashrate, I'd love to get more user data here, but it must be from runs that I know I can trust from a statistical standpoint.

The second thing is even weird:

This is my PPT for my Vega 64:
https://imgur.com/a/NTuNGjT

P0->p6 core are disable and P0->P2 mem too  and for the last state I use 875mV but when I check HWinfo when mining voltage is still around 895 mV.

Look like it use the higher voltage of disable state when running.

So I try to change my PPT by using 820mV for all state except the last one for core and mem.
I keep the exact same P7 core and P3 mem but my card is reporting dead almost one min after starting to mine.

Any explanation ?

Newer drivers often seem to lock P7 core+P3 mem during load to not be too aggressive with switching p-states.

For the PPT itself, this is an artform. Don't be fooled by the view in ODNT. The only thing that exists is a single vdd lookup table which is _shared_ by core and mem states. ODNT fools you into believing that you can separate voltage settings for e.g. core P4 from mem P3, which isn't true unless you do some serious PPT tweaking. I'm not 100% it's possible even then.

To simplify your tests, I'd either (1) use the same target voltage for ALL core and mem states in your PPT or (2) make sure all core and mem states have increasing voltage levels in respective series and also that core P4 voltage == mem P3 voltage and that it matches your target.

I'm not 100% sure what happens in your tests. Maybe mem P3 is rather grabbed from core P4, so in your first test you get 900 mV (~= 895 mV), and in your second test you get 820 mV which is way too low to handle sustained pressure?



Thanks so much for the answer , for the bad pool hashrate I just reinstalled 18.6.1 drivers , now seems to be ok . Didn't know what happens.

For the PPT , I checked all my rig ( all running at 895 mV for the good one ) even when I set up 850 mV Core P7 And Mem P3.
When I try to lower voltage for CORE P4 and above I get a crash everytime ( vega 56 and vega 64).
Two ideas : I just lost silicon lotery for all card or my PPT are really bad.

Running  drivers 18.6.1
Soc Clock : 1107 ( VEga 64 and 56)
I cannot use mem timing , too much increase in heat and consumption.
I will try to test other PPT.

Iamtutut
Member
**
Offline Offline

Activity: 700
Merit: 85


View Profile
April 22, 2019, 03:53:29 PM
 #1355

Are we going to see heavy (heaven) algo support in TeamRed? Current implementation of SRBminer is poor compute-wise optimized and needs high gpu clocks and a lot of power ((

If you want to mine Haven, just use JCE CN miner. Although the development has stopped, Heavy algos work very fine with it.
Mashy81
Jr. Member
*
Offline Offline

Activity: 223
Merit: 1


View Profile
April 22, 2019, 06:54:20 PM
 #1356

Are we going to see heavy (heaven) algo support in TeamRed? Current implementation of SRBminer is poor compute-wise optimized and needs high gpu clocks and a lot of power ((

If you want to mine Haven, just use JCE CN miner. Although the development has stopped, Heavy algos work very fine with it.

I too am eager to try TRM heavy as every CN they have implemented has been a big advance on other soffware
Iamtutut
Member
**
Offline Offline

Activity: 700
Merit: 85


View Profile
April 22, 2019, 06:58:51 PM
 #1357

It uses less power (5-10%), but it's not faster.
pbfarmer
Member
**
Offline Offline

Activity: 316
Merit: 24


View Profile
April 22, 2019, 07:06:30 PM
Last edit: April 22, 2019, 07:38:07 PM by pbfarmer
 #1358

FYI, I completed an evaluation between win10 driver 18.6.1 vs 19.4.2. Found no hashrate/power draw difference with TRM 0.4.4 miner. Evaluated on CNR algo only.

Still using ODNT? How do you set your fan speeds? IIRC there is no target temp in the beta version.

I tested a few 19.x drivers recently, on a 3x vega 56 rig, TRM 0.4.2 (also CNR only) and came to the same conclusion. Didn't have enough time to play with ODNT, but it felt weird having to spend time tweaking fan speeds. Target temp has been a set and forget kind of thing for me so...     

You can set your target temp in PPT...

Vega (hex short, byteswapped -- e.g. "1c,00" => 0x001c => 0d28):



Polaris (hex char -- e.g. "28" => 0x28 => 0d40):



Thank you for that!! It seems to be working! Your posts have always been immensely helpful.

I can't try the beta ODNT right now as I'm currently on old drivers and it's crashing so, am I right to assume the fan speed section can still be disabled in beta?

Np - happy to help.  I don't know about disabling, but ODNT just reads the value from PPT, so you shouldnt need to worry about it, unless you want to change it.

It doesn't seem to be reading it from PPT, I just double checked to make sure. Apparently it just defaults to 75 no matter what value I set in PPT. So unless the fan section can still be disabled in newer ODNT versions, it will just override whatever is set in PPT apparently.

Sorry - was thinking more of older versions.  Don’t have much exp w/ windows since 19.2. Based on what @kerney666 said, it sounds to me like fan support is actually broken in later drivers.  Like you, I’ve always found target temp to work perfectly in the past, but wattman still provided working fan curve support for those inclined.

Seems like the new fan curve impl has borked a number of things.
fluxy12
Jr. Member
*
Offline Offline

Activity: 143
Merit: 1


View Profile
April 22, 2019, 07:09:10 PM
 #1359

I still cannot understand why heavy algo's have not been implemented.

Perhaps it already exist and is used in private like Bitmain does with their Asics  Grin

Just kidding Smiley
pbfarmer
Member
**
Offline Offline

Activity: 316
Merit: 24


View Profile
April 22, 2019, 07:32:17 PM
 #1360

The second thing is even weird:

This is my PPT for my Vega 64:


P0->p6 core are disable and P0->P2 mem too  and for the last state I use 875mV but when I check HWinfo when mining voltage is still around 895 mV.

Look like it use the higher voltage of disable state when running.

So I try to change my PPT by using 820mV for all state except the last one for core and mem.
I keep the exact same P7 core and P3 mem but my card is reporting dead almost one min after starting to mine.

Any explanation ?

Thanks so much for the answer , for the bad pool hashrate I just reinstalled 18.6.1 drivers , now seems to be ok . Didn't know what happens.

For the PPT , I checked all my rig ( all running at 895 mV for the good one ) even when I set up 850 mV Core P7 And Mem P3.
When I try to lower voltage for CORE P4 and above I get a crash everytime ( vega 56 and vega 64).
Two ideas : I just lost silicon lotery for all card or my PPT are really bad.

Running  drivers 18.6.1
Soc Clock : 1107 ( VEga 64 and 56)
I cannot use mem timing , too much increase in heat and consumption.
I will try to test other PPT.


I’m betting the issue w/ being stuck @ 900mv is due to you having set p0 @ 900.  Even though you have lower states locked out in ODNT, you would already be at 900 in your idle state, before ODNT is ever involved.  This may very well prevent you from ever going lower.

Best practice is to have voltages in PPT be coded as a floor - this allows it to serve its purpose (removing the uv barrier,) while staying out of the way otherwise.  Your idea of setting 820 across the board except for top states is moving in the right direction (though I believe default p0 is actually 800, so 820 is still high.). As for why that approach causes crashes - only thing I can think is that 900 has been a threshold voltage for 1200 SOC in my exp.  Are you sure you’re running 1107 SOC?  As in, that’s what’s reported in hwinfo under load?
Pages: « 1 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 [68] 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!