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

[fluxy12]

Actually it's going to have to be a lot later as I'm currently experimenting more with merge-mining. Funky stuff that. Throws me back to 2014... When we were merge-mining crap like Fantomcoin and Moneta Verde... or Quazarcoin... or Digitalnote, lmao!

Todxx and Kerney, we need some CN Heavy/Heaven love for TRM!

Yes please focus on it, all community is asking it. I'll be happy to return to teamred (my favorite miner) when heavy algo's are here. Turtlecoin is cool, but it's a shitty coin nothing compared to bittube or haven.

[fenomenyaa]

0.4.3 CNR algo GPU initialization(very low hash or no start) problem on half my rigs.0.4.2 no problem so far.

[rednoW]

my vegas 64 liquid didn't want to go below 875mv (850 in gpu-z) with soc clock 1107 (needed for mem clock 1100). It results in 19.6khs
For 1140 mem clock (1199 soc clock) they need 900mv (875 in gpu-z). It results in 20.2khs

It doesn't depend on gpu clock - only soc clock is setting min required voltage.

vega 56 ref samsung with stock bios is happily mines with 825mv (800 in gpu-z) with 940 mem clock resulting 19.5khs

That's not necessarily true...  SOC and core appear to share power lines (which explains their relationship in bios/ppt) - I've seen many cases where a specific voltage which didn't seem to be enough for 1107 SOC was suddenly fine when I dropped core low enough.  Ethash was a great algo to test this on, as you can run Vegas at p0 w/ no performance effect.  CN-trtl is similar in this regard - while we may not be able to go all the way down to 850 Mhz cclock, 1100 is perfectly performant, and leaves a lot of power headroom for SOC/IF, resulting in lower required voltages.

In short, it's really the combination of core clock + SOC clock which determines your voltage requirement.

yes, thanks.

I disable non needed power states on Overdriventool beta and now able to run my vegas 64LC at ~1280/1100@800mv with 19.6khs. gpu-z power readings 105-115watt
I'm on win10 19.3.3 drivers

how disable? disabe what?
pls copy your overdrivetool profile... and ppt table...

i use 800mv for all p1-5 state but vega64LE vork only with p7 870mv+

Only memory states disabled. You may need to reset/reboot system. Don't use Afterburner. It seems to conflict with this low settings for vega64lc (strange)

[kerney666]

Actually it's going to have to be a lot later as I'm currently experimenting more with merge-mining. Funky stuff that. Throws me back to 2014... When we were merge-mining crap like Fantomcoin and Moneta Verde... or Quazarcoin... or Digitalnote, lmao!

Todxx and Kerney, we need some CN Heavy/Heaven love for TRM!

Yes please focus on it, all community is asking it. I'll be happy to return to teamred (my favorite miner) when heavy algo's are here. Turtlecoin is cool, but it's a shitty coin nothing compared to bittube or haven.

Yeah, reason for pushing trtl first was rather the Loki fork. We will add the 4MB variants that still are active, I promise. It will probably be 1+ week from now though.

[livada]

my vegas 64 liquid didn't want to go below 875mv (850 in gpu-z) with soc clock 1107 (needed for mem clock 1100). It results in 19.6khs
For 1140 mem clock (1199 soc clock) they need 900mv (875 in gpu-z). It results in 20.2khs

It doesn't depend on gpu clock - only soc clock is setting min required voltage.

vega 56 ref samsung with stock bios is happily mines with 825mv (800 in gpu-z) with 940 mem clock resulting 19.5khs

That's not necessarily true...  SOC and core appear to share power lines (which explains their relationship in bios/ppt) - I've seen many cases where a specific voltage which didn't seem to be enough for 1107 SOC was suddenly fine when I dropped core low enough.  Ethash was a great algo to test this on, as you can run Vegas at p0 w/ no performance effect.  CN-trtl is similar in this regard - while we may not be able to go all the way down to 850 Mhz cclock, 1100 is perfectly performant, and leaves a lot of power headroom for SOC/IF, resulting in lower required voltages.

In short, it's really the combination of core clock + SOC clock which determines your voltage requirement.

yes, thanks.

I disable non needed power states on Overdriventool beta and now able to run my vegas 64LC at ~1280/1100@800mv with 19.6khs. gpu-z power readings 105-115watt
I'm on win10 19.3.3 drivers

how disable? disabe what?
pls copy your overdrivetool profile... and ppt table...

i use 800mv for all p1-5 state but vega64LE vork only with p7 870mv+

https://i.imgur.com/BpTnO2x.png
Only memory states disabled. You may need to reset/reboot system. Don't use Afterburner. It seems to conflict with this low settings for vega64lc (strange)

ok thx

you use 1548GPU or 1280gpu?

first you say " run my vegas 64LC at ~1280/1100@800mv with 19.6khs." but in table i see 1548gpu

[Ragnarok01]

Dear dev,
I really look forward to the function of the failover pool in pools.txt file!

[Marvell2]

trying do this merged mining thing here but whats the flag for CN turtle ? this does not work

:: Example batch file for starting teamredminer.  Please fill in all <fields> with the correct values for you.
:: Format for running miner:
::      teamredminer.exe -a <algo> -o stratum+tcp://<pool address>:<pool port> -u <pool username/wallet> -p <pool password> --cn_config <cn config>
::
:: Fields:
::      algo - the name of the algorithm to run. E.g. lyra2z, phi2, or cnv8
::      pool address - the host name of the pool stratum or it's IP address. E.g. lux.pickaxe.pro
::      pool port - the port of the pool's stratum to connect to.  E.g. 8332
::      pool username/wallet - For most pools, this is the wallet address you want to mine to.  Some pools require a username
::      pool password - For most pools this can be empty.  For pools using usernames, you may need to provide a password as configured on the pool.
::      cn config - An optional thread intensity and mode to use for cryptonight mining.  See the --help option and CNV8_TUNING.txt for more info.
::
:: Example:
setx GPU_MAX_HEAP_SIZE 100
setx GPU_MAX_USE_SYNC_OBJECTS 1
setx GPU_SINGLE_ALLOC_PERCENT 100
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_MAX_SINGLE_ALLOC_PERCENT 100

set host=%COMPUTERNAME%
echo %host%

FOR /f "tokens=1,2 delims=-" %%a IN ("%host%") do echo %%a& set hostid=%%b

echo %hostid%


teamredminer.exe -a cnr -o lokiturtle.herominers.com:10521 -u LK8CGQ17G9R3ys3Xf33wCeViD2B95jgdpjAhcRsjuheJ784dumXn7g3RPAzedWpFq364jJKYL9dkQ8m Y66sZG9BiCxmZ6QJGD8s8w3rHw3 -p TRTLv1Hqo3wHdqLRXuCyX3MwvzKyxzwXeBtycnkDy8ceFp4E23bm3P467xLEbUusH6Q1mqQUBiYwJ2y ULJbvr5nKe8kcyc4uyps+2e4f04e675118d26f4f090e3e9b8c9ba1eb3b992decbf0826a52be8f369c2142@%hostid%

the -a flag for turtle is not on your help page

[kerney666]

trying do this merged mining thing here but whats the flag for CN turtle ? this does not work

:: Example batch file for starting teamredminer.  Please fill in all <fields> with the correct values for you.
:: Format for running miner:
::      teamredminer.exe -a <algo> -o stratum+tcp://<pool address>:<pool port> -u <pool username/wallet> -p <pool password> --cn_config <cn config>
::
:: Fields:
::      algo - the name of the algorithm to run. E.g. lyra2z, phi2, or cnv8
::      pool address - the host name of the pool stratum or it's IP address. E.g. lux.pickaxe.pro
::      pool port - the port of the pool's stratum to connect to.  E.g. 8332
::      pool username/wallet - For most pools, this is the wallet address you want to mine to.  Some pools require a username
::      pool password - For most pools this can be empty.  For pools using usernames, you may need to provide a password as configured on the pool.
::      cn config - An optional thread intensity and mode to use for cryptonight mining.  See the --help option and CNV8_TUNING.txt for more info.
::
:: Example:
setx GPU_MAX_HEAP_SIZE 100
setx GPU_MAX_USE_SYNC_OBJECTS 1
setx GPU_SINGLE_ALLOC_PERCENT 100
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_MAX_SINGLE_ALLOC_PERCENT 100

set host=%COMPUTERNAME%
echo %host%

FOR /f "tokens=1,2 delims=-" %%a IN ("%host%") do echo %%a& set hostid=%%b

echo %hostid%


teamredminer.exe -a cnr -o lokiturtle.herominers.com:10521 -u LK8CGQ17G9R3ys3Xf33wCeViD2B95jgdpjAhcRsjuheJ784dumXn7g3RPAzedWpFq364jJKYL9dkQ8m Y66sZG9BiCxmZ6QJGD8s8w3rHw3 -p TRTLv1Hqo3wHdqLRXuCyX3MwvzKyxzwXeBtycnkDy8ceFp4E23bm3P467xLEbUusH6Q1mqQUBiYwJ2y ULJbvr5nKe8kcyc4uyps+2e4f04e675118d26f4f090e3e9b8c9ba1eb3b992decbf0826a52be8f369c2142@%hostid%

the -a flag for turtle is not on your help page

This is what I see for official release v0.4.3, algo cnv8_trtl listed last for the -a options. Did we miss it somewhere else?

Code:

C:\crypto\teamredminer-v0.4.3-win>teamredminer --help
          Team Red Miner version 0.4.3
Usage: teamredminer [OPTIONS]
Options:
  -a, --algo=ALGORITHM      Selects the mining algorithm.  Currently available:
                              lyra2z
                              phi2        (lux, argoneum)
                              lyra2rev3   (vtc)
                              cnv8
                              cnr         (monero)
                              cnv8_half   (stellite, masari)
                              cnv8_dbl    (x-cash)
                              cnv8_rwz    (graft)
                              cnv8_trtl   (turtlecoin, loki)
  -o, --url=URL             Sets the pool URL.  Currently stratum+tcp and stratum+ssl URLs are supported.
  -u, --user=USERNAME       Sets the username for pool authorization.
  -p, --pass=PASSWORD       Sets the password for pool authorization.
...

[Marvell2]

Usually most miner threads put it on the first announcement, and update it as they modify code

[pbfarmer]

Actually it's going to have to be a lot later as I'm currently experimenting more with merge-mining. Funky stuff that. Throws me back to 2014... When we were merge-mining crap like Fantomcoin and Moneta Verde... or Quazarcoin... or Digitalnote, lmao!

Todxx and Kerney, we need some CN Heavy/Heaven love for TRM!

Looks like there's a turtle/loki pair on hero.

[rednoW]

my vegas 64 liquid didn't want to go below 875mv (850 in gpu-z) with soc clock 1107 (needed for mem clock 1100). It results in 19.6khs
For 1140 mem clock (1199 soc clock) they need 900mv (875 in gpu-z). It results in 20.2khs

It doesn't depend on gpu clock - only soc clock is setting min required voltage.

vega 56 ref samsung with stock bios is happily mines with 825mv (800 in gpu-z) with 940 mem clock resulting 19.5khs

That's not necessarily true...  SOC and core appear to share power lines (which explains their relationship in bios/ppt) - I've seen many cases where a specific voltage which didn't seem to be enough for 1107 SOC was suddenly fine when I dropped core low enough.  Ethash was a great algo to test this on, as you can run Vegas at p0 w/ no performance effect.  CN-trtl is similar in this regard - while we may not be able to go all the way down to 850 Mhz cclock, 1100 is perfectly performant, and leaves a lot of power headroom for SOC/IF, resulting in lower required voltages.

In short, it's really the combination of core clock + SOC clock which determines your voltage requirement.

yes, thanks.

I disable non needed power states on Overdriventool beta and now able to run my vegas 64LC at ~1280/1100@800mv with 19.6khs. gpu-z power readings 105-115watt
I'm on win10 19.3.3 drivers

how disable? disabe what?
pls copy your overdrivetool profile... and ppt table...

i use 800mv for all p1-5 state but vega64LE vork only with p7 870mv+

Only memory states disabled. You may need to reset/reboot system. Don't use Afterburner. It seems to conflict with this low settings for vega64lc (strange)

ok thx

you use 1548GPU or 1280gpu?

first you say " run my vegas 64LC at ~1280/1100@800mv with 19.6khs." but in table i see 1548gpu

What you set in OverdriveNTool or in Wattman is not what you will get.
You'll get lower clock and voltage. At least according to gpu-z and similar apps.

[trillobeat]

What is the soft power table used together with the settings shown on this 2.8.0 beta 1 overdriventool screenshot?  Possible to share the file?

Those settings together with a brnsted powertable , amd 19.3.3 driver result in dead MSI Vega64LC (samsung memory)  gpus less than a minute mining in TR. not even changing p7 to 875 can be used to save them from failing.

[livada]

What is the soft power table used together with the settings shown on this 2.8.0 beta 1 overdriventool screenshot?  Possible to share the file?

Those settings together with a brnsted powertable , amd 19.3.3 driver result in dead MSI Vega64LC (samsung memory)  gpus less than a minute mining in TR. not even changing p7 to 875 can be used to save them from failing.

i have identical problem.

vega 64LE dead after 1 min (2sec)

i must give 880mv for gpu and mem or gpu work only 1 min or 1 sec

pls any put PPT table this for vega64_LE and vega_56

thx

[rednoW]

no powerplay tables at all. Not needed with latest drivers

[seefatlow]

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?

[GKumaran]

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.  

I can confirm the same behaviour on Vega 64 with samsung memory at L28+28, tried droping to L26+26 and still same results.
Normal : 19.56, and after some random time 19.06

[professorkuusamo]

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?

i have same situation.unstable only on trtl.try different drivers nothing change.

[kerney666]

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?

i have same situation.unstable only on trtl.try different drivers nothing change.

Hey guys!

Well, unoptimized code isn't the issue, it's rather that it's optimized so much that it's pounding the gpu more than anything we've produced before, especially the memory subsystem.

I'm not chasing efficiency to the same degree that you professional tuners are since my rig(s) are a combination of test and more serious mining. However, on my 8 x Vega 56 ref cards flashed to V64, win10, 18.6.1, clocks at 1408@900, 1100@900, I have zero stability issues, it's been mining for 14h straight now in the current run, and much longer before that as well. I've just stopped it to reconfigure things a few times.

However, on my Vega 64 Liquid Cooling in my dev workstation, CN-trtl is the first algo I've ever seen that kills that specific card but not my blower Vegas. It dies after 1-2h, also running at 1408@900, 1100@900. Effective clocks+voltages in hwinfo64 look very similar to the V56s.

Right now, I'm doing tests with the single-threaded config support that we also added in 0.4.3. This means I'm running --cn_config=L56+0 instead of --cn_config=L28+28. On my V64 LC, hashrate drops from 19.6 kh/s to 18.8 kh/s, same efficiency. The hashrate is expected to drop a little, but this should be more lean on the gpu, it won't be going full throttle on all parts of the hardware at the same time. Theory vs practice is always a bitch though, I'll report back in a few hours on the results.

Meanwhile, you're of course free to try the same trick: switch your problematic Vegas to L56+0 and see if it helps, I'd love to get some more data here.

[professorkuusamo]

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?

i have same situation.unstable only on trtl.try different drivers nothing change.

Hey guys!

Well, unoptimized code isn't the issue, it's rather that it's optimized so much that it's pounding the gpu more than anything we've produced before, especially the memory subsystem.

I'm not chasing efficiency to the same degree that you professional tuners are since my rig(s) are a combination of test and more serious mining. However, on my 8 x Vega 56 ref cards flashed to V64, win10, 18.6.1, clocks at 1408@900, 1100@900, I have zero stability issues, it's been mining for 14h straight now in the current run, and much longer before that as well. I've just stopped it to reconfigure things a few times.

However, on my Vega 64 Liquid Cooling in my dev workstation, CN-trtl is the first algo I've ever seen that kills that specific card but not my blower Vegas. It dies after 1-2h, also running at 1408@900, 1100@900. Effective clocks+voltages in hwinfo64 look very similar to the V56s.

Right now, I'm doing tests with the single-threaded config support that we also added in 0.4.3. This means I'm running --cn_config=L56+0 instead of --cn_config=L28+28. On my V64 LC, hashrate drops from 19.6 kh/s to 18.8 kh/s, same efficiency. The hashrate is expected to drop a little, but this should be more lean on the gpu, it won't be going full throttle on all parts of the hardware at the same time. Theory vs practice is always a bitch though, I'll report back in a few hours on the results.

Meanwhile, you're of course free to try the same trick: switch your problematic Vegas to L56+0 and see if it helps, I'd love to get some more data here.

56 on samsung are stable, works since release 0.4.3.crashed only in rigs with hynix.

[kerney666]

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?

i have same situation.unstable only on trtl.try different drivers nothing change.

Hey guys!

Well, unoptimized code isn't the issue, it's rather that it's optimized so much that it's pounding the gpu more than anything we've produced before, especially the memory subsystem.

I'm not chasing efficiency to the same degree that you professional tuners are since my rig(s) are a combination of test and more serious mining. However, on my 8 x Vega 56 ref cards flashed to V64, win10, 18.6.1, clocks at 1408@900, 1100@900, I have zero stability issues, it's been mining for 14h straight now in the current run, and much longer before that as well. I've just stopped it to reconfigure things a few times.

However, on my Vega 64 Liquid Cooling in my dev workstation, CN-trtl is the first algo I've ever seen that kills that specific card but not my blower Vegas. It dies after 1-2h, also running at 1408@900, 1100@900. Effective clocks+voltages in hwinfo64 look very similar to the V56s.

Right now, I'm doing tests with the single-threaded config support that we also added in 0.4.3. This means I'm running --cn_config=L56+0 instead of --cn_config=L28+28. On my V64 LC, hashrate drops from 19.6 kh/s to 18.8 kh/s, same efficiency. The hashrate is expected to drop a little, but this should be more lean on the gpu, it won't be going full throttle on all parts of the hardware at the same time. Theory vs practice is always a bitch though, I'll report back in a few hours on the results.

Meanwhile, you're of course free to try the same trick: switch your problematic Vegas to L56+0 and see if it helps, I'd love to get some more data here.

56 on samsung are stable, works since release 0.4.3.crashed only in rigs with hynix.

Got it, although I’ve gotten a nr of reports from liquid V64s having issues as well. Regardless, does anything change for you if you try L56+0 on those Hynix V56s?