Pages:
Author

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

sr. member
Activity: 1484
Merit: 253
It's just wanderfull! Auto and manual config works fine!
member
Activity: 204
Merit: 10
Awesome Update :
Results for Vega 64, Aircooled, Reference
On Windows 10, 18.6.1 Driver

AlgorithmHashratePower at wall (Watt)Efficiency (Hash/Watt)ODT ConfigTRM Config
x16r, x16s, x16rt(average- mh/s) 21.5(average) 185116.221082/ 800/812
CN R234520511.441408/1100/87516*14:AAA
CN Saber
218517712.351408/1100/87515+15:CBB
CN Haven217017312.541408/1100/87516+14:CBB
CN Turtle22340198112.831216/1100/875L26+26:AAA
CN UPX284940208408.371216/1100/875L26+26:AAA or L26+26:BAA
CN HeavyX12071866.491408/1100/87515*14:AAA

Note:  The TRM config is just for info, use the auto tuning and get the best config for your card/clock/timings.
sr. member
Activity: 1484
Merit: 253
Team Red Miner v0.5.0 released

https://github.com/todxx/teamredminer/releases

Changes in v0.5.0
  • Added cryptonight 4MB variants: heavy, haven and saber.
  • Added x16 algo suite: x16r, x16s, x16rt (both gin and veil).
  • Auto-tuning mode for all CN variants, see bundled guide.
  • Manual key-driven CN tuning mode available inside the miner.
  • Additional data in miner stats console output.
  • Watchdog now detecting single stuck thread when mining CN.
  • Fix: in rare cases, poolside hash for compute algos (lyra2z, phi2, lyra2rev3) only reached ~95% of expected value.

We've added new algos for 4MB/heavy CN variants!  Now you can mine haven/bittube with TRM Smiley
We've also added more finetuning options, as well as built-in auto-tuning to find the best config!
Wow! Exccelent update! Thanx! Let's try it!
full member
Activity: 1120
Merit: 131
member
Activity: 176
Merit: 76
Team Red Miner v0.5.0 released

https://github.com/todxx/teamredminer/releases

Changes in v0.5.0
  • Added cryptonight 4MB variants: heavy, haven and saber.
  • Added x16 algo suite: x16r, x16s, x16rt (both gin and veil).
  • Auto-tuning mode for all CN variants, see bundled guide.
  • Manual key-driven CN tuning mode available inside the miner.
  • Additional data in miner stats console output.
  • Watchdog now detecting single stuck thread when mining CN.
  • Fix: in rare cases, poolside hash for compute algos (lyra2z, phi2, lyra2rev3) only reached ~95% of expected value.

We've added new algos for 4MB/heavy CN variants!  Now you can mine haven/bittube with TRM Smiley
We've also added more finetuning options, as well as built-in auto-tuning to find the best config!
member
Activity: 658
Merit: 86
WoWnero will soon fork in RandomX it seems to me

RandomX is a very different beast, and yes wownero will fork shortly. We're not making any promises around RandomX support at this point, we'll observe what happens.
copper member
Activity: 293
Merit: 11
WoWnero will soon fork in RandomX it seems to me
newbie
Activity: 14
Merit: 0
TRM supported WOWnero mining?
jr. member
Activity: 145
Merit: 1
algo Cryptonight HeavyX and MTP when?Huh

HeavyX for X-cash is already available, it's called cnv8_dbl in TRM. We're still debating how to prioritize MTP. The issue is the big investment in time for building the custom stratum protocol, submitting those huge proofs etc, all for a single coin and algo.

there will be new coins on mtp np; very good project tecracoin, mtp has a future

how do you know MTP is the future?HuhHuhHuh what do I know progpow -maybe it's the future.. why MTP it is Huh

He said "mtp HAS a future" not "is the future" that's not exactly the same meaning Smiley

newbie
Activity: 60
Merit: 0
algo Cryptonight HeavyX and MTP when?Huh

HeavyX for X-cash is already available, it's called cnv8_dbl in TRM. We're still debating how to prioritize MTP. The issue is the big investment in time for building the custom stratum protocol, submitting those huge proofs etc, all for a single coin and algo.

there will be new coins on mtp np; very good project tecracoin, mtp has a future

how do you know MTP is the future?HuhHuhHuh what do I know progpow -maybe it's the future.. why MTP it is Huh
newbie
Activity: 20
Merit: 0
algo Cryptonight HeavyX and MTP when?Huh

HeavyX for X-cash is already available, it's called cnv8_dbl in TRM. We're still debating how to prioritize MTP. The issue is the big investment in time for building the custom stratum protocol, submitting those huge proofs etc, all for a single coin and algo.

there will be new coins on mtp np; very good project tecracoin, mtp has a future
jr. member
Activity: 194
Merit: 4
Hey Kerney.

I had PMed you in the MMP OS Discord for a weird issue.

2 days ago, i experencied a crashed GPU, its a 570 4GB.

System is Win 10 1703, AMD 19.2.1, 4GB RAM, i5-3470.

The GPU would die for no reason (maybe timings).

The GPU stats reporting will stop, and only the share submitting will remain. API is getting killed as well.
But the miner itself does not seem to react properly with the dead GPU, as no SICK/DEAD is declared (and the API should still be responsive).

Miner does not initiate properly the shutdown process, or at the very least, output is not shown. The GPUs did stop mining though.

Trying to invoke the Task Manager or the AMD Radeon Settings freezes them almost right away. Even the driver does not know if its crashed or not Cheesy

EDIT2: Here are the screenshots.
https://imgur.com/a/fu3Zkxj

I presume, it could be overheating, since yesterday crashed again at 81*C.

EDIT: Also, i see that the Interleaving adjustment happens primarily on the GPU0 (shortly after the miner initialization).

EDIT3: When the card was run with lower voltage (core + IMC), it crashed, and it was detected and declared as DEAD. Will try again, by raising the voltage, to see if the issue will repeat.

Hi ku4eto! Thanks for the edit updates. Any more info after bumping voltage a little?

Okay, after some testing, i got in the past 2 days, 3-4 more crashes in total.

After playing with the voltage for that card (retesting the stability, in case it has degraded), but the voltage initially used was indeed correct.
Bumping up the voltage by 2 steps (2x6.25mV) had no difference.

I set the fan today to 95% for above 75*C (was for 85*C before that). I have not observed the issue still.

I will check for 2 more days, before calling it 100% an thermal issue.

Its a RX 570 Gigabyte Aorus. Not sure, but i believe some cards had a different thermal limit for some elements, compared to the rest. Although, i did compare the BIOS, and it had the same temp limits defined, as the rest of my cards.
newbie
Activity: 12
Merit: 1
I may have missed it, but:
What does the
Quote
GPU0 thread 0 interleave adjust xxx ms
means?

For dual thread CN mining to keep its highest hashrate over time you need to make sure the two threads are running with the appropriate separation in time. If they gravitate and become too close to running synchronously, the whole point of running dual threads disappears. Therefore, it's better to delay one of the threads a little before starting the next hash run. This is the "interleave adjustment" logged above. As long as your hashrate is stable (and high) over time, it's nothing to worry about, everything is working as intended.

Asking, because i saw it on only one card. And this one tends to crash every week or two.

I have the same problem.
VEGA 56 is normal in the case of "mode 16+14".
However, the same problem occurs after using AMD Mem Tweak & "--cn_config 1x*1x".
And after a while, it will drop from 2000 h/s to 16xx h/s.
Is it an overclocking problem? Is there any solution?

I have had issues with various Vega 56's that had the same problems that you mention (drop from 2000 h/s to 16xx h/s or just crash). The problems usually a few days to happen. The solution I have found is to increase the core voltage in small increments until the problems disappear. I also had to down the core clock speed.


Example: Vega 56: Core 920mv and 1300 MHz core. I also run the mode as 14*14. I still get around 2000 H/s (no memory tweak done yet)

Core 920 mv, much better than before.
Thank you.
member
Activity: 658
Merit: 86
Hey Kerney.

I had PMed you in the MMP OS Discord for a weird issue.

2 days ago, i experencied a crashed GPU, its a 570 4GB.

System is Win 10 1703, AMD 19.2.1, 4GB RAM, i5-3470.

The GPU would die for no reason (maybe timings).

The GPU stats reporting will stop, and only the share submitting will remain. API is getting killed as well.
But the miner itself does not seem to react properly with the dead GPU, as no SICK/DEAD is declared (and the API should still be responsive).

Miner does not initiate properly the shutdown process, or at the very least, output is not shown. The GPUs did stop mining though.

Trying to invoke the Task Manager or the AMD Radeon Settings freezes them almost right away. Even the driver does not know if its crashed or not Cheesy

EDIT2: Here are the screenshots.
https://imgur.com/a/fu3Zkxj

I presume, it could be overheating, since yesterday crashed again at 81*C. May

EDIT: Also, i see that the Interleaving adjustment happens primarily on the GPU0 (shortly after the miner initialization).

EDIT3: When the card was run with lower voltage (core + IMC), it crashed, and it was detected and declared as DEAD. Will try again, by raising the voltage, to see if the issue will repeat.

Hi ku4eto! Thanks for the edit updates. Any more info after bumping voltage a little?
member
Activity: 658
Merit: 86
I may have missed it, but:
What does the
Quote
GPU0 thread 0 interleave adjust xxx ms
means?

For dual thread CN mining to keep its highest hashrate over time you need to make sure the two threads are running with the appropriate separation in time. If they gravitate and become too close to running synchronously, the whole point of running dual threads disappears. Therefore, it's better to delay one of the threads a little before starting the next hash run. This is the "interleave adjustment" logged above. As long as your hashrate is stable (and high) over time, it's nothing to worry about, everything is working as intended.

Asking, because i saw it on only one card. And this one tends to crash every week or two.

I have the same problem.
VEGA 56 is normal in the case of "mode 16+14".
However, the same problem occurs after using AMD Mem Tweak & "--cn_config 1x*1x".
And after a while, it will drop from 2000 h/s to 16xx h/s.
Is it an overclocking problem? Is there any solution?

watch your hbm temps.  you may be over-temp throttling

Hi! When you exit the miner after this happens, do you get a clean shutdown or is one thread timing out? The 2000 to 1600 h/s drop is very close to the expected single threaded performance, I’m guessing one thread has died.
member
Activity: 340
Merit: 29
I may have missed it, but:
What does the
Quote
GPU0 thread 0 interleave adjust xxx ms
means?

For dual thread CN mining to keep its highest hashrate over time you need to make sure the two threads are running with the appropriate separation in time. If they gravitate and become too close to running synchronously, the whole point of running dual threads disappears. Therefore, it's better to delay one of the threads a little before starting the next hash run. This is the "interleave adjustment" logged above. As long as your hashrate is stable (and high) over time, it's nothing to worry about, everything is working as intended.

Asking, because i saw it on only one card. And this one tends to crash every week or two.

I have the same problem.
VEGA 56 is normal in the case of "mode 16+14".
However, the same problem occurs after using AMD Mem Tweak & "--cn_config 1x*1x".
And after a while, it will drop from 2000 h/s to 16xx h/s.
Is it an overclocking problem? Is there any solution?

watch your hbm temps.  you may be over-temp throttling
member
Activity: 214
Merit: 24
I may have missed it, but:
What does the
Quote
GPU0 thread 0 interleave adjust xxx ms
means?

For dual thread CN mining to keep its highest hashrate over time you need to make sure the two threads are running with the appropriate separation in time. If they gravitate and become too close to running synchronously, the whole point of running dual threads disappears. Therefore, it's better to delay one of the threads a little before starting the next hash run. This is the "interleave adjustment" logged above. As long as your hashrate is stable (and high) over time, it's nothing to worry about, everything is working as intended.

Asking, because i saw it on only one card. And this one tends to crash every week or two.

I have the same problem.
VEGA 56 is normal in the case of "mode 16+14".
However, the same problem occurs after using AMD Mem Tweak & "--cn_config 1x*1x".
And after a while, it will drop from 2000 h/s to 16xx h/s.
Is it an overclocking problem? Is there any solution?

I have had issues with various Vega 56's that had the same problems that you mention (drop from 2000 h/s to 16xx h/s or just crash). The problems usually a few days to happen. The solution I have found is to increase the core voltage in small increments until the problems disappear. I also had to down the core clock speed.


Example: Vega 56: Core 920mv and 1300 MHz core. I also run the mode as 14*14. I still get around 2000 H/s (no memory tweak done yet)
newbie
Activity: 12
Merit: 1
I may have missed it, but:
What does the
Quote
GPU0 thread 0 interleave adjust xxx ms
means?

For dual thread CN mining to keep its highest hashrate over time you need to make sure the two threads are running with the appropriate separation in time. If they gravitate and become too close to running synchronously, the whole point of running dual threads disappears. Therefore, it's better to delay one of the threads a little before starting the next hash run. This is the "interleave adjustment" logged above. As long as your hashrate is stable (and high) over time, it's nothing to worry about, everything is working as intended.

Asking, because i saw it on only one card. And this one tends to crash every week or two.

I have the same problem.
VEGA 56 is normal in the case of "mode 16+14".
However, the same problem occurs after using AMD Mem Tweak & "--cn_config 1x*1x".
And after a while, it will drop from 2000 h/s to 16xx h/s.
Is it an overclocking problem? Is there any solution?
jr. member
Activity: 194
Merit: 4
Hey Kerney.

I had PMed you in the MMP OS Discord for a weird issue.

2 days ago, i experencied a crashed GPU, its a 570 4GB.

System is Win 10 1703, AMD 19.2.1, 4GB RAM, i5-3470.

The GPU would die for no reason (maybe timings).

The GPU stats reporting will stop, and only the share submitting will remain. API is getting killed as well.
But the miner itself does not seem to react properly with the dead GPU, as no SICK/DEAD is declared (and the API should still be responsive).

Miner does not initiate properly the shutdown process, or at the very least, output is not shown. The GPUs did stop mining though.

Trying to invoke the Task Manager or the AMD Radeon Settings freezes them almost right away. Even the driver does not know if its crashed or not Cheesy

EDIT2: Here are the screenshots.
https://imgur.com/a/fu3Zkxj

I presume, it could be overheating, since yesterday crashed again at 81*C. May

EDIT: Also, i see that the Interleaving adjustment happens primarily on the GPU0 (shortly after the miner initialization).

EDIT3: When the card was run with lower voltage (core + IMC), it crashed, and it was detected and declared as DEAD. Will try again, by raising the voltage, to see if the issue will repeat.
member
Activity: 658
Merit: 86
algo Cryptonight HeavyX and MTP when?Huh

HeavyX for X-cash is already available, it's called cnv8_dbl in TRM. We're still debating how to prioritize MTP. The issue is the big investment in time for building the custom stratum protocol, submitting those huge proofs etc, all for a single coin and algo.
Pages:
Jump to: