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

[todxx]

Have any of you guys played around with editing HBM2 memory timings on linux?

If anyone has a reference V64/V56/FE card with Samsung Mem on linux and is feeling adventurous, could you guys try the following timings?
--rp 10 --rc 45 --rfc 290

Please keep in mind that editing timings can result in damage to your cards.
These timings work for me on my Vega FE, but there's no guarantee they will work for other cards.
In particular, I'm curious what your cn trtl results are.  Timings currently have a very limited impact on our other kernels.

any idea on the reason it can damage?  heat?

I get 40+ KHs on VII on cn-trtl without the memory mods @ 1450 core and 1295 HBM2.

Well, usually changing timings will only result in memory errors, which will quickly crash the card and nothing particularly bad happens.
But if you screw up the timings badly enough, you can get situations where you have both the dram and the memory controller driving the bus in opposite directions.
Even this will usually not result in damage because both the mem controller and dram have limited drive strength these days, but it still puts more stress on parts then what they are designed for.
Heat is always an issue, and that's just something you have to manage when overclocking anyway.

All of that said, I really don't expect anyone to actually damage their cards, especially not with those timings since I've already tested them on one of my cards.
But just like with any other type of overclocking, I feel it's good for people to know that you can damage components if you go nuts with the values.

[Iamtutut]

Have any of you guys played around with editing HBM2 memory timings on linux?

If anyone has a reference V64/V56/FE card with Samsung Mem on linux and is feeling adventurous, could you guys try the following timings?
--rp 10 --rc 45 --rfc 290

Please keep in mind that editing timings can result in damage to your cards.
These timings work for me on my Vega FE, but there's no guarantee they will work for other cards.
In particular, I'm curious what your cn trtl results are.  Timings currently have a very limited impact on our other kernels.

any idea on the reason it can damage?  heat?

I get 40+ KHs on VII on cn-trtl without the memory mods @ 1450 core and 1295 HBM2.

Close to the speed of 5 RX574, the VII really is impressive.

[pbfarmer]

Have any of you guys played around with editing HBM2 memory timings on linux?

If anyone has a reference V64/V56/FE card with Samsung Mem on linux and is feeling adventurous, could you guys try the following timings?
--rp 10 --rc 45 --rfc 290

Please keep in mind that editing timings can result in damage to your cards.
These timings work for me on my Vega FE, but there's no guarantee they will work for other cards.
In particular, I'm curious what your cn trtl results are.  Timings currently have a very limited impact on our other kernels.

any idea on the reason it can damage?  heat?

I get 40+ KHs on VII on cn-trtl without the memory mods @ 1450 core and 1295 HBM2.

Do you know who manufactured your mem?  I seem to have gotten Hynix, and I only saw 32 kh/s - Granted I only went to 1200, but the diff between 1050 and 1200 was maybe 2kh/s tops, so not sure how another 100mhz would make such a big difference.

[tvukoman]

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?

[heavyarms1912]

Do you know who manufactured your mem?  I seem to have gotten Hynix, and I only saw 32 kh/s - Granted I only went to 1200, but the diff between 1050 and 1200 was maybe 2kh/s tops, so not sure how another 100mhz would make such a big difference.

Mine's Hynix.  100 Mhz will bump it sure but not to 40.  I am using single thread on VII.  I am on 19.3.x drivers.

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.

[GKumaran]

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.

I was also lured by the no ppt arguments. Either i need to use wattman or my cards silicon are crap.

I gave up and used the same 850mv ppt and ran at L26+26 getting 19.61 kh @ 1408/1100/850mv on 19.3.3.

[Germini]

what is the best web monitoring for this miner?

kerney666 said sometime ago "I have some plans on getting a little Python hack going that acts as an adapter against the messier sgminer API and provides an xmr stak equivalent html and http/json interface. Time time time."

Maybe an adapter for claymore monitor or xmr-stak

[seefatlow]

Have any of you guys played around with editing HBM2 memory timings on linux?

If anyone has a reference V64/V56/FE card with Samsung Mem on linux and is feeling adventurous, could you guys try the following timings?
--rp 10 --rc 45 --rfc 290

Please keep in mind that editing timings can result in damage to your cards.
These timings work for me on my Vega FE, but there's no guarantee they will work for other cards.
In particular, I'm curious what your cn trtl results are.  Timings currently have a very limited impact on our other kernels.

any idea on the reason it can damage?  heat?

I get 40+ KHs on VII on cn-trtl without the memory mods @ 1450 core and 1295 HBM2.

What's your ATW power draw for VII?

[pbfarmer]

what is the best web monitoring for this miner?

kerney666 said sometime ago "I have some plans on getting a little Python hack going that acts as an adapter against the messier sgminer API and provides an xmr stak equivalent html and http/json interface. Time time time."

Maybe an adapter for claymore monitor or xmr-stak

https://github.com/rdugan/cgminerhttpinterface

After installing, you can add this to your miner startup bat to auto-start the server if it's not already running.  Doesn't auto-close tho.

Code:

SET HTTP_PORT=8080
SET API_HOST=localhost
SET API_PORT=4028

QPROCESS "chi-server.exe">NUL
IF %ERRORLEVEL% EQU 0 GOTO :startMiner

start /min "TRM Monitor" chi-server -w %HTTP_PORT% -a %API_HOST% -p %API_PORT%

:startMiner

...

[GKumaran]

what is the best web monitoring for this miner?

kerney666 said sometime ago "I have some plans on getting a little Python hack going that acts as an adapter against the messier sgminer API and provides an xmr stak equivalent html and http/json interface. Time time time."

Maybe an adapter for claymore monitor or xmr-stak

I use this one : https://dashboard.foreman.mn/dashboard/
Pretty much a one stop for all miner and algos.

[dragonmike]

OK. I have been trying over several days to replicate the results from pbfarmer on cnv8_trtl and I can say that I am unable to get the efficiency reported by him. Any attempt to reach close to his reported voltage levels of 805mv to 840mV resulted in random DEAD GPUs(stuck in enqueue) after 20-30 minutes hashing or significant hashrate drop per GPU


Even at 870mV, I am still unable to get a stable system running. Dead GPUs and hashrate drop to 15kH/s still occurs after several tens of minutes of mining. And the weird thing is hashrate drops happens to Hynix mem GPUs only.   Somehow CN-TRTL algo is more taxing that CN_R? I am able to run CN_R without failures for a week and with lower voltage settings (850mV - 870mV). I can't seem to do this for CN_TRTL

My settings are as below. But the hashrates aren't sustainable

GPUs : Ref Vega 64 and Vega 56 reference bios
V64 cclk/memclk 1220/1100 @ 870mV L28+28 (Samsung mem) - 19.5kH/s
V56 cclk/memclk 1220/940 @ 870mV L24+24 (Samsung mem) - 19.3kH/s  (Hynix mem) - 18.7 kH/s
ATW power draw 190W per GPU
Adrenalin Driver 18.6.1


Kerney/Todd,

Any ideas what could possibly be wrong? Unoptimized CN_TRTL code?

That's quite weird, out of my six reference Vega56's (flashed to 64), 4 are hashing rock solid at 1408@825 core / 1107 mem and the weaker two cards get 850mV.
I reckon I could potentially go even lower.
Have you fiddled with your power play tables? Is your SoC set higher? That's quite typical for instability, I can sing a song or two about it...

DragonMike, my SOC on reference V56 (bios V64) is 1199, i think it is becouse i use "Safe" ppt file that u/Hellea make. That is only ppt table that for some reason work stable.
I want to try lower SOC to 1107.

Can you (or someone) share ppt with lover SOC 1107 that work ok for reference V56 (bios changed to V64 samsung mem)?

txs

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.

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

[livada]

OK. I have been trying over several days to replicate the results from pbfarmer on cnv8_trtl and I can say that I am unable to get the efficiency reported by him. Any attempt to reach close to his reported voltage levels of 805mv to 840mV resulted in random DEAD GPUs(stuck in enqueue) after 20-30 minutes hashing or significant hashrate drop per GPU


Even at 870mV, I am still unable to get a stable system running. Dead GPUs and hashrate drop to 15kH/s still occurs after several tens of minutes of mining. And the weird thing is hashrate drops happens to Hynix mem GPUs only.   Somehow CN-TRTL algo is more taxing that CN_R? I am able to run CN_R without failures for a week and with lower voltage settings (850mV - 870mV). I can't seem to do this for CN_TRTL

My settings are as below. But the hashrates aren't sustainable

GPUs : Ref Vega 64 and Vega 56 reference bios
V64 cclk/memclk 1220/1100 @ 870mV L28+28 (Samsung mem) - 19.5kH/s
V56 cclk/memclk 1220/940 @ 870mV L24+24 (Samsung mem) - 19.3kH/s  (Hynix mem) - 18.7 kH/s
ATW power draw 190W per GPU
Adrenalin Driver 18.6.1


Kerney/Todd,

Any ideas what could possibly be wrong? Unoptimized CN_TRTL code?

That's quite weird, out of my six reference Vega56's (flashed to 64), 4 are hashing rock solid at 1408@825 core / 1107 mem and the weaker two cards get 850mV.
I reckon I could potentially go even lower.
Have you fiddled with your power play tables? Is your SoC set higher? That's quite typical for instability, I can sing a song or two about it...

DragonMike, my SOC on reference V56 (bios V64) is 1199, i think it is becouse i use "Safe" ppt file that u/Hellea make. That is only ppt table that for some reason work stable.
I want to try lower SOC to 1107.

Can you (or someone) share ppt with lover SOC 1107 that work ok for reference V56 (bios changed to V64 samsung mem)?

txs

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.

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

i try to PM but you not received newbie pm

pls send me your ppt table. i have ref vega56(samsung) with 64 bios
i have vega 64LE
and vega 56 nitro+ (hynix) standard bios

pls send me any table. i try with all card but minimum vega vork is 860mv. all lees = dead gpu.
i chg SOC 1107 1099 but 860mv gpu/mem is minimum for work

my mail is livada2@gmail.com

thx

[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??

[cas333]

After a lot of testing i can personally say that 0.4.2 works better than 0.4.3. No crashes with rx 570(80) 8gb cards on auto settings. Switched back to the old one

[heavyarms1912]

I get 40+ KHs on VII on cn-trtl without the memory mods @ 1450 core and 1295 HBM2.

What's your ATW power draw for VII?

~200w.

[kerney666]

After a lot of testing i can personally say that 0.4.2 works better than 0.4.3. No crashes with rx 570(80) 8gb cards on auto settings. Switched back to the old one

It seems we're really approaching weird hardware limits in general with CN mining. The changes between TRM 0.4.2 and 0.4.3, man... Let's just say that they are very very subtle, except for the addition of kernels for CN-turtle of course. Nothing in the other changes motivate any form of statistically significant change in behavior, but, here we are...

Still, can you describe the changes you're seeing? Is it at startup or randomly after a longer period of time? Same gpu(s) or random? OS?

[cas333]

After a lot of testing i can personally say that 0.4.2 works better than 0.4.3. No crashes with rx 570(80) 8gb cards on auto settings. Switched back to the old one

It seems we're really approaching weird hardware limits in general with CN mining. The changes between TRM 0.4.2 and 0.4.3, man... Let's just say that they are very very subtle, except for the addition of kernels for CN-turtle of course. Nothing in the other changes motivate any form of statistically significant change in behavior, but, here we are...

Still, can you describe the changes you're seeing? Is it at startup or randomly after a longer period of time? Same gpu(s) or random? OS?

Thanks for your reply! OS w10 1809,random gpus dead,some algos at startup and some after 30min to 2 hours. Crazy limits you are approaching i think too.  0.4.2 is super stable for me,so you know better where is the key

[pbfarmer]

@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?

[ZombieWorm]

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. 

[tvukoman]

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     ║
╚═════════════════════════════╩═════════╩══════╩══════╩══════════╩══════════╩════════╩════════╩═════════╝