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

[kerney666]

Running it on rx580 8gb, i got 8.6Kh@128W or 8Kh/s@109W downvolting.

Been messing with one of mine... But RX570 4gb L16+16 and seem to be running 8.2 khs.

I haven't found any better combos than that for the config.

JCE CN GPU miner is still faster then.

Except for my bad GPU (MSI Gaming), my 574s get +/- 8,5KH/s.

Man, I'm just going to let this one pass. I know you love JCE, and I truly only have good things to say about JCE and his miner, he's one of the few miner devs I've cared for interacting with over PM. But, "still faster then", oh boy... Since you're using CN-turtle as a benchmark, you know we're like +10-15% ahead of all other miners for CN-turtle on Vegas, esp with Samsung HBM, right? In many cases with a lower overall power draw?

[1714006743]

1714006743

[1714006743]

1714006743

[1714006743]

1714006743

[1714006743]

1714006743

[dragonmike]

@pbfarmer: I'm currently testing my Vegas at 1258 core (OT setting) @ 807mV and they seem to hold for now (except for two weaker cards that won't have anything less than 850mV even at low clocks).

EDIT: 807 didn't cut it. It mined as I changed it on the fly, but would not initialise at this voltage. 815 seems to work (both init and mining) - Couple of hours going, so far so good.

EDIT2: 815 held for a few hours but ended up crashing in the end. Reducing core clocks further doesn't seem to increase stability, maybe there really is a balance to be found.

Yeah, this is a tough nut to crack - esp for those couple salty cards you inevitably run into.  I'm kinda figuring out that you have to tune this a bit backwards from the normal process - stability seems to be all about mem (SOC) speed + cn_config.  Core speed tuning on it's own doesn't do much - cclocks only real importance seems to be in determining which cn_config you can use.  This is roughly what i'm seeing:

L28+28: >= 1150mhz
L26+26: 1050mhz - 1150mhz
L22+22: 950mhz - 1050mhz (not sure about this one...)
L18+18: 850mhz - 950?mhz

The relationship isn't cleanly linear - i've seen cn_config 'holes' where for instance, in one case L26+26 is fine, L24+24 is crap, L22+22 is good again.  And in other cases, I've run into tight couplings, where even reducing cn_config incrementally caused instability.

I'm tempted to just run all my vegas like i do for ethash - 850 (core-p0) / 1107 (mem-p3) / L18+18 - and then tune voltage as needed.  It's straightforward (no acg, everything fixed except voltage,) low power, and i still get 18.5kh/s out of it.

L24+24 is fastest for Vega56's I think. Im getting over 19.5kH/s using that setting.

[kerney666]

Just Update win 10 pro (to last version) + driver to 19.3.2 version from 18.6.1 because no need for ppt table and read that this driver is OK. Update OverdriveNtool to last 0.28.beta 1 too.

Strange: CNR on 19.3.2 work just like on 18.6.1 driver but Turtle algo with 19.3.2 driver on Vega 56 (64 bios) or Vega 64 (Asus) drop hashrate from 18 kh/s to 10 kh/s

Did someone try turtle algo on 19.3.2?

Seems like I am not the only one.  I had similar results.  L28+28 gives 10-11 Khs.  Try 26+26, it would work fine around 17-18.5 Khs still not as good as other folks who can get L28+28 with earlier drivers.

heavyarms1912 txs!

Confirmed:

Asus Strix Vega 64, 26+26 on 19.3.2 driver results with 19,4 kh/s (on 18.6.1 result was about 18,5 kh/s)
Reference Vega 56 (64bios), 26+26 on 19.3.2. driver 18 kh/s (on 18.6.1 result was equal)

Here is test on 19.3.2 for CNR algo, after testing all configs, this is the best results with power from the wall (for rig). Testing Vega from 13+13 to 16+15 and 5+5 to 8+7 on rx570 with all combinations. EDIT: Reference Vega cards can do more, I put clock down because overheating (small space about two m2 without windows, just small holes and one small bathroom fan ;-))
╔═════════════════════════════╦═════════╦══════╦══════╦══════════╦══════════╦════════╦════════╦═════════╗
║ Card                        ║ Memory  ║ Algo ║ kh/s ║ Core     ║ Mem      ║ Config ║ Driver ║ Power W ║
╠═════════════════════════════╬═════════╬══════╬══════╬══════════╬══════════╬════════╬════════╬═════════╣
║ Asus Strix Vega 64          ║ Samsung ║ CNR  ║ 2210 ║ 1520/920 ║ 1100/910 ║ 16+14  ║ 19.3.2 ║ 787     ║
╠═════════════════════════════╬═════════╬══════╬══════╬══════════╬══════════╬════════╬════════╬═════════╣
║ Reference Vega 56 Gigabyte x 2  ║ Samsung ║ CNR  ║ 1970 ║ 1408/950 ║ 1050/950 ║ 14+14  ║ 19.3.2 ║ 787     ║
╠═════════════════════════════╬═════════╬══════╬══════╬══════════╬══════════╬════════╬════════╬═════════╣
║ Rx570 4GB Nitro+            ║ Elpida  ║ CNR  ║ 940  ║ 1180/850 ║ 1980/900 ║ 7+7    ║ 19.3.2 ║ 787     ║
╚═════════════════════════════╩═════════╩══════╩══════╩══════════╩══════════╩════════╩════════╩═════════╝

As a comparison, I just fire up my rig with 8 x ref Vega 56 flashed to 64, win10, 18.6.1 driver, L24+24, 19.5 kh/s per gpu, no fuss whatsoever. There are some very strange things happening in later drivers, hard to come up with good theories. I'll bump my dev workstation with 580+V64+VII to 19.3.2 shortly, will be interesting to see if I get the same weird behavior. It's also weird that my 18.6.1 rig and tvukoman's V56-flashed-64 on 18.6.1 is getting very different results.

[seefatlow]

Just Update win 10 pro (to last version) + driver to 19.3.2 version from 18.6.1 because no need for ppt table and read that this driver is OK. Update OverdriveNtool to last 0.28.beta 1 too.

Strange: CNR on 19.3.2 work just like on 18.6.1 driver but Turtle algo with 19.3.2 driver on Vega 56 (64 bios) or Vega 64 (Asus) drop hashrate from 18 kh/s to 10 kh/s

Did someone try turtle algo on 19.3.2?

Seems like I am not the only one.  I had similar results.  L28+28 gives 10-11 Khs.  Try 26+26, it would work fine around 17-18.5 Khs still not as good as other folks who can get L28+28 with earlier drivers.

heavyarms1912 txs!

Confirmed:

Asus Strix Vega 64, 26+26 on 19.3.2 driver results with 19,4 kh/s (on 18.6.1 result was about 18,5 kh/s)
Reference Vega 56 (64bios), 26+26 on 19.3.2. driver 18 kh/s (on 18.6.1 result was equal)

Here is test on 19.3.2 for CNR algo, after testing all configs, this is the best results with power from the wall (for rig). Testing Vega from 13+13 to 16+15 and 5+5 to 8+7 on rx570 with all combinations. EDIT: Reference Vega cards can do more, I put clock down because overheating (small space about two m2 without windows, just small holes and one small bathroom fan ;-))
╔═════════════════════════════╦═════════╦══════╦══════╦══════════╦══════════╦════════╦════════╦═════════╗
║ Card                        ║ Memory  ║ Algo ║ kh/s ║ Core     ║ Mem      ║ Config ║ Driver ║ Power W ║
╠═════════════════════════════╬═════════╬══════╬══════╬══════════╬══════════╬════════╬════════╬═════════╣
║ Asus Strix Vega 64          ║ Samsung ║ CNR  ║ 2210 ║ 1520/920 ║ 1100/910 ║ 16+14  ║ 19.3.2 ║ 787     ║
╠═════════════════════════════╬═════════╬══════╬══════╬══════════╬══════════╬════════╬════════╬═════════╣
║ Reference Vega 56 Gigabyte x 2  ║ Samsung ║ CNR  ║ 1970 ║ 1408/950 ║ 1050/950 ║ 14+14  ║ 19.3.2 ║ 787     ║
╠═════════════════════════════╬═════════╬══════╬══════╬══════════╬══════════╬════════╬════════╬═════════╣
║ Rx570 4GB Nitro+            ║ Elpida  ║ CNR  ║ 940  ║ 1180/850 ║ 1980/900 ║ 7+7    ║ 19.3.2 ║ 787     ║
╚═════════════════════════════╩═════════╩══════╩══════╩══════════╩══════════╩════════╩════════╩═════════╝

As a comparison, I just fire up my rig with 8 x ref Vega 56 flashed to 64, win10, 18.6.1 driver, L24+24, 19.5 kh/s per gpu, no fuss whatsoever. There are some very strange things happening in later drivers, hard to come up with good theories. I'll bump my dev workstation with 580+V64+VII to 19.3.2 shortly, will be interesting to see if I get the same weird behavior. It's also weird that my 18.6.1 rig and tvukoman's V56-flashed-64 on 18.6.1 is getting very different results.

Devs,

Really appreciate if you can report Hynix mem performance as well where most of us have the unfortunate privilege of owning. All the reports on Samsung memory doesn't translate at all to Hynix for the more taxing algo (CN-turtle as an example).

 

[seefatlow]

Just Update win 10 pro (to last version) + driver to 19.3.2 version from 18.6.1 because no need for ppt table and read that this driver is OK. Update OverdriveNtool to last 0.28.beta 1 too.

Strange: CNR on 19.3.2 work just like on 18.6.1 driver but Turtle algo with 19.3.2 driver on Vega 56 (64 bios) or Vega 64 (Asus) drop hashrate from 18 kh/s to 10 kh/s

Did someone try turtle algo on 19.3.2?

Seems like I am not the only one.  I had similar results.  L28+28 gives 10-11 Khs.  Try 26+26, it would work fine around 17-18.5 Khs still not as good as other folks who can get L28+28 with earlier drivers.

heavyarms1912 txs!

Confirmed:

Asus Strix Vega 64, 26+26 on 19.3.2 driver results with 19,4 kh/s (on 18.6.1 result was about 18,5 kh/s)
Reference Vega 56 (64bios), 26+26 on 19.3.2. driver 18 kh/s (on 18.6.1 result was equal)

Here is test on 19.3.2 for CNR algo, after testing all configs, this is the best results with power from the wall (for rig). Testing Vega from 13+13 to 16+15 and 5+5 to 8+7 on rx570 with all combinations. EDIT: Reference Vega cards can do more, I put clock down because overheating (small space about two m2 without windows, just small holes and one small bathroom fan ;-))
╔═════════════════════════════╦═════════╦══════╦══════╦══════════╦══════════╦════════╦════════╦═════════╗
║ Card                        ║ Memory  ║ Algo ║ kh/s ║ Core     ║ Mem      ║ Config ║ Driver ║ Power W ║
╠═════════════════════════════╬═════════╬══════╬══════╬══════════╬══════════╬════════╬════════╬═════════╣
║ Asus Strix Vega 64          ║ Samsung ║ CNR  ║ 2210 ║ 1520/920 ║ 1100/910 ║ 16+14  ║ 19.3.2 ║ 787     ║
╠═════════════════════════════╬═════════╬══════╬══════╬══════════╬══════════╬════════╬════════╬═════════╣
║ Reference Vega 56 Gigabyte x 2  ║ Samsung ║ CNR  ║ 1970 ║ 1408/950 ║ 1050/950 ║ 14+14  ║ 19.3.2 ║ 787     ║
╠═════════════════════════════╬═════════╬══════╬══════╬══════════╬══════════╬════════╬════════╬═════════╣
║ Rx570 4GB Nitro+            ║ Elpida  ║ CNR  ║ 940  ║ 1180/850 ║ 1980/900 ║ 7+7    ║ 19.3.2 ║ 787     ║
╚═════════════════════════════╩═════════╩══════╩══════╩══════════╩══════════╩════════╩════════╩═════════╝

How many devices are you running in your rig? 787W ATW for 3 Vegas + 1 Polaris seems somewhat inefficient especially for the hashrates you are getting. I think you should be able to undervolt further by reducing your cclock to 1450/870 1100/870 and still maintain 2.1kh hashrate. Have you given that a try?

[trillobeat]

This is how my three MSI Vega 64LC (Samsung mem) are doing at loki+turtle using TRM 0.4.3, cn_config setting L28+28, driver amd 18.6.1, win 10 pro 1903; GB z270p-d3 board :

https://imgur.com/6vi5VwS      -  the overdriventool values (the brnsted soft power table values)

https://imgur.com/M7UwQUb     - the trm 0.4.3 hash rate

https://imgur.com/W2Q9Dh4      -  hdwinfo

With this power table and the 18.6.1 driver the Vegas can mine days on end, no stability issues.


I tried 19.3.3. driver and settings mentioned on page 57 here and the cards didn't last a minute.At  cn_config L56 the bat file would not even run, terminal closed immediately.   

[Beyerd17]

I am thinking about mining Monero (cryptonight R). I have 3 290x gpu's. My electricity is about 12 cent. As far as I can see profitability will be weak to say the least, should I wait for Monero to rise in value or would the hashrate kill of profitability anyways??

I had a 290x for years and sold it on to make way for vega56. Even with your cheap electric you will be mining at a loss on current prices. Should XMR rise to over £60 you may get to cover the electricity cost, you are likely needing something near to 2x before those cards will yield any profit. 

So what you are basically saying is that I should sell them on Ebay or something. Don't think they will be worth much, so not sure I can be bothered to sell. Think I'll keep them in hope of cryptoprices exploding some day.

[Iamtutut]

I am thinking about mining Monero (cryptonight R). I have 3 290x gpu's. My electricity is about 12 cent. As far as I can see profitability will be weak to say the least, should I wait for Monero to rise in value or would the hashrate kill of profitability anyways??

I had a 290x for years and sold it on to make way for vega56. Even with your cheap electric you will be mining at a loss on current prices. Should XMR rise to over £60 you may get to cover the electricity cost, you are likely needing something near to 2x before those cards will yield any profit. 

So what you are basically saying is that I should sell them on Ebay or something. Don't think they will be worth much, so not sure I can be bothered to sell. Think I'll keep them in hope of cryptoprices exploding some day.

I you can afford your electricity bill with the 290X and you believe coin prices will go up, then mine small coins.

[seefatlow]

@pbfarmer: I'm currently testing my Vegas at 1258 core (OT setting) @ 807mV and they seem to hold for now (except for two weaker cards that won't have anything less than 850mV even at low clocks).

EDIT: 807 didn't cut it. It mined as I changed it on the fly, but would not initialise at this voltage. 815 seems to work (both init and mining) - Couple of hours going, so far so good.

EDIT2: 815 held for a few hours but ended up crashing in the end. Reducing core clocks further doesn't seem to increase stability, maybe there really is a balance to be found.

Yeah, this is a tough nut to crack - esp for those couple salty cards you inevitably run into.  I'm kinda figuring out that you have to tune this a bit backwards from the normal process - stability seems to be all about mem (SOC) speed + cn_config.  Core speed tuning on it's own doesn't do much - cclocks only real importance seems to be in determining which cn_config you can use.  This is roughly what i'm seeing:

L28+28: >= 1150mhz
L26+26: 1050mhz - 1150mhz
L22+22: 950mhz - 1050mhz (not sure about this one...)
L18+18: 850mhz - 950?mhz

The relationship isn't cleanly linear - i've seen cn_config 'holes' where for instance, in one case L26+26 is fine, L24+24 is crap, L22+22 is good again.  And in other cases, I've run into tight couplings, where even reducing cn_config incrementally caused instability.

I'm tempted to just run all my vegas like i do for ethash - 850 (core-p0) / 1107 (mem-p3) / L18+18 - and then tune voltage as needed.  It's straightforward (no acg, everything fixed except voltage,) low power, and i still get 18.5kh/s out of it.

EDIT: cn_config numbers are for V64 - maybe scale down by 4 for V56?

I just don't understand how you guys are able to pull off <850mV voltage at the said memclk . My one and only MSI Reference Vega64 at the very same setting is only stable above 870mV.

[dragonmike]

@pbfarmer: I'm currently testing my Vegas at 1258 core (OT setting) @ 807mV and they seem to hold for now (except for two weaker cards that won't have anything less than 850mV even at low clocks).

EDIT: 807 didn't cut it. It mined as I changed it on the fly, but would not initialise at this voltage. 815 seems to work (both init and mining) - Couple of hours going, so far so good.

EDIT2: 815 held for a few hours but ended up crashing in the end. Reducing core clocks further doesn't seem to increase stability, maybe there really is a balance to be found.

Yeah, this is a tough nut to crack - esp for those couple salty cards you inevitably run into.  I'm kinda figuring out that you have to tune this a bit backwards from the normal process - stability seems to be all about mem (SOC) speed + cn_config.  Core speed tuning on it's own doesn't do much - cclocks only real importance seems to be in determining which cn_config you can use.  This is roughly what i'm seeing:

L28+28: >= 1150mhz
L26+26: 1050mhz - 1150mhz
L22+22: 950mhz - 1050mhz (not sure about this one...)
L18+18: 850mhz - 950?mhz

The relationship isn't cleanly linear - i've seen cn_config 'holes' where for instance, in one case L26+26 is fine, L24+24 is crap, L22+22 is good again.  And in other cases, I've run into tight couplings, where even reducing cn_config incrementally caused instability.

I'm tempted to just run all my vegas like i do for ethash - 850 (core-p0) / 1107 (mem-p3) / L18+18 - and then tune voltage as needed.  It's straightforward (no acg, everything fixed except voltage,) low power, and i still get 18.5kh/s out of it.

EDIT: cn_config numbers are for V64 - maybe scale down by 4 for V56?

I just don't understand how you guys are able to pull off <850mV voltage at the said memclk . My one and only MSI Reference Vega64 at the very same setting is only stable above 870mV.

Post your overdriventool profile in here please.
Also, have you got your SoC clock set to 1200 or is it still at the stock 1107? That's been the culprit for many people, including me, to get this thing to work properly.

[playfast]

I have my RX560's rock stable on Win 10 LTSB mining either XMR/GRFT, but disappointed they can only do L2+3 stable, bumping up to L3+3 loses hashrate or crashes.
Nearly every RX550 post I see them reported to easily handle L3+3 and some 3+4 plus go very low on the core/voltage for super efficiency.
Do most RX550 Lexa's actually come with stronger memory than RX560 Baffin's ?

[dragonmike]

As an update from more testing by yours truly...

Lower clocks have a larger overall stability impact than I thought they would. It seems that going below 1250 MHz core clock on Vegas comes with LESS stability at the same voltage. pbfarmer is probably on to something by tweaking the cn_configs downwards win parallel with lowering clocks.

So it seems that 1250@825 core is a sweetspot (mem clocks always remain unchanged at 1107) for Vega56's at L24+24. They still hash north of 19.5 KH/s there.

Probably won't bother trying to go lower with lower intensities as that's where hashrate starts to drop.

My rig of 6 Vegas draws less than 1170W at the wall using the settings above on TRTL+Loki. That's quite remarkable.

[tvukoman]

Sorry dude, I only just saw this.
If you want to revert to 18.6.1 and try my PPT table, I'm happy to send it to you.
Just dm me your email address in that case.

I'm using reference Sapphire RX Vega 56 with 64 bios, so the ppt will reflect that.

I had SoC set to 1200 previously and that wreaked total havoc in my cards' behaviour. Always massive pain to get the cards stable, needed to increase core voltages massively and they just behaved erratically. Getting SoC back to 1107 sorted everything.

Dragonmike, PM is sent.

I have another hard disk with installation of miner on win10 1709 with 18.6.1. driver (that system I used until now).

So I can easily test, just boot from another disk ;-)

txs

[pbfarmer]

pbfarmer is probably on to something by tweaking the cn_configs downwards win parallel with lowering clocks.

Honestly - that's kinda normal for any miner, but the difference here is that power use is so tightly coupled w/ the 'intensity' setting, and can swing so significantly w/ an incremental change.  Because of this, it kinda makes more sense to choose your cn_config first, then find the cclock that supports it.

I pulled the trigger and went w/ 850 cclock (p0), 1107 mclock (p3), L18+18 across the board on my V64 rig, and I would *highly* recommend it to anyone looking for max efficiency and/or simple setup.  On average, I see a 15-20w (11+%) drop in power for a 1kh/s (5%) drop in hashrate, and it couldn't be more simple, given that all you have to adjust is voltage. 

Bottom line, that's 18.5 kh/s for ~138w vs 19.5 kh/s for ~155w on average, without all the trouble searching for intensity, clock, and power combinations.





Btw, I've also tested this on my V64 flashed ref V56, and i'm seeing similar efficiency gains (19.4 -> 18.3kh/s, 150 -> 135w,) but w/ cn_config=L22+22

[pbfarmer]

@kerney666 / @todxx - a couple hopefully easy requests/fixes...

1. Just noticed in my screenshot it shows "12:68:33".  Not sure how we get to 68 minutes...
2. Any chance you can change 34 (blue) to 36 (cyan) for the h/r printout?  Blue is hard to see, at least on a black terminal bg (i just pipe to 'tr' for now.)

[Iamtutut]

Devs, turtlecoin devs will implement Argon2iD at height 1 800 000, could you implement this ago in your miner ?

[kerney666]

Devs, turtlecoin devs will implement Argon2iD at height 1 800 000, could you implement this ago in your miner ?

Hi, just saw that today as well. I can't make any promises at this point though, it's a very small use case for a new algo .

[kerney666]

@kerney666 / @todxx - a couple hopefully easy requests/fixes...

1. Just noticed in my screenshot it shows "12:68:33".  Not sure how we get to 68 minutes...
2. Any chance you can change 34 (blue) to 36 (cyan) for the h/r printout?  Blue is hard to see, at least on a black terminal bg (i just pipe to 'tr' for now.)

Wow, that's funny. The code that extracts that nr from a sec timestamp is

Code:

(int)((uptime/60) % 60)

I have to be blind, I can't find anything bad.

For cyan vs blue - we already had to do that exact change on Windows b/c the blue there was a sibling of pitch black. Cyan looked nice on my linux terminal(s), but I can look into it.

[pbfarmer]

@kerney666 / @todxx - a couple hopefully easy requests/fixes...

1. Just noticed in my screenshot it shows "12:68:33".  Not sure how we get to 68 minutes...
2. Any chance you can change 34 (blue) to 36 (cyan) for the h/r printout?  Blue is hard to see, at least on a black terminal bg (i just pipe to 'tr' for now.)

Wow, that's funny. The code that extracts that nr from a sec timestamp is

Code:

(int)((uptime/60) % 60)

I have to be blind, I can't find anything bad.

For cyan vs blue - we already had to do that exact change on Windows b/c the blue there was a sibling of pitch black. Cyan looked nice on my linux terminal(s), but I can look into it.

n/m re #1 - it's because of my pipe to tr for the color change.  Same reason some of my temps show 60c in that screenshot...  Forgot i should be using perl/awk/sed for this.  sorry

[Iamtutut]

Many projects follow turtlecoin implementations, and I won't be surprised to see the coins focused on minability and decentralization going on this algo, you'll get a lead advantage. XTRI devs are already thinking of changing their algo.