 Show Posts
|
|
Pages: [1] 2 »
|
|
@Zminer777
Why have you removed vprogpow in 2.40 ?
I thought vprogpow algo with have active VBK coin would not be removed so soon, it's NOT like Equihash 96/5 which was used on long ago dead MNX coin.
Now it turns out that I'm only poor soul mining VBK with your miner.
|
|
|
|
 Mining VBK getting constantly that devfee pools are unavailable. |
|
|
|
|
for RVN don't use parameter -a
use just
-coin rvn
|
|
|
|
|
4
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: miniZ, fast & friendly Equihash 144,5 150,5,3 125,4 192,7 210,9 150,5 96,5 miner
|
on: February 11, 2020, 11:00:18 PM
|
Hi hogwash.89m,
Sorry to hear that there have been some issues going on.
Just to completely discard the OCs interference, have you tried mining in stock settings?
Could you let us know what algorithm are you running? And to which pool?
We will have a look into it, maybe we can reproduce this behavior.
Thanks for the feedback!
Cheers
Hi miniz, Sorry, I didn't write which algo is in question. 150,5,3 – BeamHashII sunpool Also I didn't log the output so I can't show if there had been any error in console. Last 2 days I was mining with 1.5 s version without issue, only there was one crash, and then for like 15 hours it was OK again. [ 2d 7h15m43s|Feb 11 08:16:11] S:6645/1 257(257.1)Sol/s 779(773.6)W [beam.sunpool.top]
0>GTX 1080 Ti ` 100% [59øC/47%] 27.94 I/s 55.8(55.9)Sol/s 176(173.7)W clk=1632MHz mclk=5702MHz Sol/W=0.32
1>GTX 1080 ` 100% [59øC/47%] 20.54 I/s 40.8(40.8)Sol/s 124(122.4)W clk=1556MHz mclk=5200MHz Sol/W=0.33
2>GTX 1080 `99.9% [57øC/45%] 20.14 I/s 40.4(39.9)Sol/s 118(118.5)W clk=1531MHz mclk=5200MHz Sol/W=0.34
3>GTX 1080 ` 100% [57øC/44%] 20.36 I/s 40.1(40.4)Sol/s 121(120.5)W clk=1556MHz mclk=5200MHz Sol/W=0.34
4>GTX 1080 ` 100% [51øC/40%] 19.98 I/s 38.7(39.5)Sol/s 117(115.7)W clk=1518MHz mclk=5200MHz Sol/W=0.34
5>GTX 1080 ` 100% [58øC/46%] 20.46 I/s 40.4(40.7)Sol/s 123(122.3)W clk=1556MHz mclk=5200MHz Sol/W=0.33
[FATAL ] GPU[3]: CUDA error 77 'an illegal memory access was encountered' in line 1013
[INFO ] Disconnecting from beam.sunpool.top
[FATAL ] GPU[4]: CUDA error 77 'an illegal memory access was encountered' in line 1013
[FATAL ] GPU[2]: CUDA error 77 'an illegal memory access was encountered' in line 1013
[FATAL ] GPU[5]: CUDA error 77 'an illegal memory access was encountered' in line 1013
[FATAL ] GPU[1]: CUDA error 77 'an illegal memory access was encountered' in line 1013
[FATAL ] GPU[0]: CUDA error 77 'an illegal memory access was encountered' in line 1013 This popped out in log, this was with kind a extreme optimization and OC. It's strange that error is for all GPUs, I hope it's error for pool. It was happening before that once in 2-3 days there are miner crash and batch loop starts it again. Now I started 1.5 t without any OC, only power limit down to ~180W for 1080ti and ~120W for 1080. I don't like that extra heat and noise  . I will report in day or two how is going. |
|
|
|
|
5
|
Alternate cryptocurrencies / Mining (Altcoins) / Re: miniZ, fast & friendly Equihash 144,5 150,5,3 125,4 192,7 210,9 150,5 96,5 miner
|
on: February 09, 2020, 12:45:59 AM
|
I think there is a problem with 1.5t version.  Around 2. Feb I updated to 1.5t version, and from then 3 times I got one card "minining" with 0 Sol/s (or 0 point something). First time I thought that it could be faulty pci-e riser, they are almost 2 years old, then I restated miner with same setting (also same OC) and then again after like 12-24 hours different card drop to 0 Sol/s. Then I lower OC settings to confirm if it's something wrong with cards, and then after almost 2 days 3rd card drop to 0 Sol/s, in all cases power consumption also dropped to idle. All 3 cars are GTX 1080, in a rig with 1x 1080ti + 5x 1080, with fee-time set to 40 sec and OC1 but later I saw that that is not supported on 1080. So I reverted to 1.5s to confirm if it's hardware problem or problem with new miner version. There wasn't any changes to driver or other software. On 1.5s I was mining for more than 2 months without a problem. Only minor defect on 1.5s is that miner was switching to dev fee but cards actually wasn't mining (gpu usage was 0, power consumption idle) but luckly they always returned to mining properly to pool. |
|
|
|
|
Also noticed regression in performance on 1080, and as I don't want to increase PL% I will continue to use miniZ miner, which works nicely on 1080 (PL ~130W and --oc1).
|
|
|
|
Hi miniZ dev. Been running 1.3n5 version for a few days, and it happens that miner just crashed without error after a 1 day of mining, last time it was after 1 day and 6 hours. [ 1d 6h 3m00s] S:17342/0 167(165.9)Sol/s 817(826.5)W [beam-eu.sparkpool.com]
0>GTX 1080 Ti ` 100% [60°C/46%] 18.87 I/s 38.3(37.7)Sol/s 175(180.5)W clk=1506MHz mclk=5865MHz Sol/W=0.21
1>GTX 1080 ` 100% [61°C/47%] 12.78 I/s 25.7(25.4)Sol/s 126(129.0)W clk=1468MHz mclk=5346MHz Sol/W=0.20
2>GTX 1080 ` 100% [59°C/45%] 12.85 I/s 24.9(25.4)Sol/s 129(129.1)W clk=1518MHz mclk=5346MHz Sol/W=0.20
3>GTX 1080 ` 100% [59°C/45%] 13.04 I/s 25.9(25.8)Sol/s 129(129.0)W clk=1569MHz mclk=5346MHz Sol/W=0.20
4>GTX 1080 ` 100% [55°C/43%] 12.86 I/s 26.1(25.6)Sol/s 133(129.3)W clk=1493MHz mclk=5346MHz Sol/W=0.20
5>GTX 1080 ` 100% [60°C/46%] 12.95 I/s 25.5(25.7)Sol/s 125(129.2)W clk=1493MHz mclk=5346MHz Sol/W=0.20
Waiting for 0 seconds, press a key to continue ...
************ miniZ v1.3n5 ************
Number of CUDA devices found: 6
miniZ,150,5[8:1:00]: Selecting GPU#0[0] GeForce GTX 1080 Ti
miniZ,150,5[4:1:00]: Selecting GPU#1[1] GeForce GTX 1080
miniZ,150,5[4:1:00]: Selecting GPU#2[2] GeForce GTX 1080
miniZ,150,5[4:1:00]: Selecting GPU#3[3] GeForce GTX 1080
miniZ,150,5[4:1:00]: Selecting GPU#4[4] GeForce GTX 1080
miniZ,150,5[4:1:00]: Selecting GPU#5[5] GeForce GTX 1080
Algo: EQ[150,5]
Pool#0: user[14794c3bea134979c40773495734d655e561224a4e5bc3600d81886457223e0c5.rig0] server[beam-eu.sparkpool.com] port[2222] ssl[yes] pers[Beam-PoW]
Pool#1: user[2fdc7c988d1a2181a191b5c4290c018656098094a9a12d0ca94bafa914bdb75c7.rig0] server[beam-eu.leafpool.com] port[4444] ssl[yes] pers[Beam-PoW]
Optimisation: oc1[1 2 3 4 5] oc2[0]
Temp. limit: [70°C]
[ 0d 0h 0m09s] S: 1/0 141(141.0)Sol/s 400(400.4)W [beam-eu.sparkpool.com]
0>GTX 1080 Ti ` 100% [56°C/43%] 16.67 I/s 30.2(30.2)Sol/s 83( 82.9)W clk=2050MHz mclk=5865MHz Sol/W=0.36
1>GTX 1080 ` 100% [55°C/44%] 11.50 I/s 20.9(20.9)Sol/s 133(132.9)W clk=1480MHz mclk=5346MHz Sol/W=0.16
2>GTX 1080 ` 100% [53°C/43%] 11.19 I/s 20.9(20.9)Sol/s 45( 45.5)W clk=1771MHz mclk=5346MHz Sol/W=0.46
3>GTX 1080 ` 100% [52°C/43%] 11.35 I/s 21.4(21.4)Sol/s 45( 45.2)W clk=1771MHz mclk=5346MHz Sol/W=0.47
4>GTX 1080 ` 100% [48°C/41%] 11.19 I/s 22.0(22.0)Sol/s 44( 43.6)W clk=1607MHz mclk=5346MHz Sol/W=0.50
5>GTX 1080 ` 100% [53°C/43%]*11.23 I/s 20.8(20.8)Sol/s 50( 50.3)W clk=2062MHz mclk=5346MHz Sol/W=0.41 Same settings for all cards. PL 72% core +180 mem +360 |
|
|
|
|
Hi devs,
Why you don't implement nice total average hash counter?
But it's always floating between 160 Sol/s - 164 Sol/s (on my rig mining BEAM).
I was doing some testing Gminer 1.41 vs miniZ 1.3n5 and even they looks like close in console on sparkpool difference is bigger.
after 24h average 154 Sol/s vs 159 Sol/s
|
|
|
|
Hi MineOrDie, hogwash.89m, Thank you for your suggestion. We will try to know more details about the new upcoming ZEL algo, but if they stay in the equihash domain it is likely that we will support  Cheers It's definitely flavour of equihash, they are aiming to do something similarly as 150_5 (BEAM) Equihash with custom datapath, but will also focus on making modifications which would prevent FPGA to gain much performance advantage ove GPUs (or atleast as minimal as possible). And they plan to release it on testnet soon. That are only information which I have. Have a nice day. And can confirm that --oc1 on 1080 gives extra 1 Sol/s * With following settings (topping to 25.5 - 26 Sol/s, with efficiency of 0.20 Sol/W) : PL 72%
Core +180
Mem +340
Currently, when miner crashes, for example with these errors: [FATAL ] GPU[0]: CUDA error 30 'unknown error' in func 'eq_:80C8>5_2~3]>4:e0aB, SM, PS2>::solve' line 1119
[FATAL ] GPU[2]: CUDA error 30 'unknown error' in func 'eq_:80C8>5_2~3]>4:e0aB, SM, PS2>::solve' line 1119
[FATAL ] GPU[4]: CUDA error 30 'unknown error' in func 'eq_:80C8>5_2~3]>4:e0aB, SM, PS2>::solve' line 1119
[FATAL ] GPU[1]: CUDA error 30 'unknown error' in func 'eq_:80C8>5_2~3]>4:e0aB, SM, PS2>::solve' line 1119
[FATAL ] GPU[3]: CUDA error 30 'unknown error' in func 'eq_:80C8>5_2~3]>4:e0aB, SM, PS2>::solve' line 1119
[FATAL ] GPU[5]: CUDA error 30 'unknown error' in func 'eq_:80C8>5_2~3]>4:e0aB, SM, PS2>::solve' line 1119 An error window pops up and miner halts Can you make it so that the error window does not pop up? Also, just make the miner restart? It's Windows Error reporting settings which shown that dialog, and blocks miner restart until user action. Save this code in .reg file and execute it. This is adding dword to registry (or add it manually, it's quite readable), and it disables showing Error Reporting dialog UI when program error happens, like when miner throws a error. Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"DontShowUI"=dword:00000001 Or same thing via elevated (admin) CMD reg command, result is same. Which ever you prefer. https://superuser.com/a/715645 |
|
|
|
Hey,
ZEL will have an upcoming algo change to ther unique algo, can you maybe reach out to them, offer your help and be the one who will provide the most optimized miner when they release their upgraded network?
Also n5 gives me a bit lower hashrate on 144,5 compared to n4.
Spending some development time on new ZelHash algo (new ZEL antiFPGA/ASIC algo) would be nice, as it's promising coin. |
|
|
|
Error when mining on dev [fee.server]. 5>GTX 1080 ` 100% [60°C/49%] 12.32 I/s 24.4(24.4)Sol/s 128(129.3)W clk=1518MHz mclk=5355MHz Sol/W=0.19
[ 0d 3h34m14s] S:1990/0 159(159.6)Sol/s 825(824.0)W [fee.server]
0>GTX 1080 Ti ` 100% [61°C/51%] 18.70 I/s 36.7(37.5)Sol/s 182(179.8)W clk=1493MHz mclk=5899MHz Sol/W=0.21
1>GTX 1080 ` 100% [61°C/51%] 12.14 I/s 24.0(24.1)Sol/s 128(128.6)W clk=1379MHz mclk=5355MHz Sol/W=0.19
2>GTX 1080 ` 100% [60°C/49%] 12.15 I/s 24.3(24.2)Sol/s 125(129.1)W clk=1468MHz mclk=5355MHz Sol/W=0.19
3>GTX 1080 ` 100% [60°C/49%] 12.43 I/s 24.8(24.7)Sol/s 130(128.9)W clk=1493MHz mclk=5355MHz Sol/W=0.19
4>GTX 1080 ` 100% [54°C/45%] 12.43 I/s 25.2(24.6)Sol/s 133(129.2)W clk=1531MHz mclk=5355MHz Sol/W=0.19
5>GTX 1080 ` 100% [60°C/49%] 12.32 I/s 23.9(24.4)Sol/s 127(129.3)W clk=1404MHz mclk=5355MHz Sol/W=0.19
0:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:..\..\openssl-1.1.0f\ssl\record\ssl3_record.c:210:
Hi hogwash.89m, thanks for reporting this. We never had that error. We are looking into this. Cheers It happens sometimes, after long run. And I think it can be connected to sudden crush when mining on fee.server, it happens to me once. This error I saw few times already. |
|
|
|
Error when mining on dev [fee.server]. 5>GTX 1080 ` 100% [60°C/49%] 12.32 I/s 24.4(24.4)Sol/s 128(129.3)W clk=1518MHz mclk=5355MHz Sol/W=0.19
[ 0d 3h34m14s] S:1990/0 159(159.6)Sol/s 825(824.0)W [fee.server]
0>GTX 1080 Ti ` 100% [61°C/51%] 18.70 I/s 36.7(37.5)Sol/s 182(179.8)W clk=1493MHz mclk=5899MHz Sol/W=0.21
1>GTX 1080 ` 100% [61°C/51%] 12.14 I/s 24.0(24.1)Sol/s 128(128.6)W clk=1379MHz mclk=5355MHz Sol/W=0.19
2>GTX 1080 ` 100% [60°C/49%] 12.15 I/s 24.3(24.2)Sol/s 125(129.1)W clk=1468MHz mclk=5355MHz Sol/W=0.19
3>GTX 1080 ` 100% [60°C/49%] 12.43 I/s 24.8(24.7)Sol/s 130(128.9)W clk=1493MHz mclk=5355MHz Sol/W=0.19
4>GTX 1080 ` 100% [54°C/45%] 12.43 I/s 25.2(24.6)Sol/s 133(129.2)W clk=1531MHz mclk=5355MHz Sol/W=0.19
5>GTX 1080 ` 100% [60°C/49%] 12.32 I/s 23.9(24.4)Sol/s 127(129.3)W clk=1404MHz mclk=5355MHz Sol/W=0.19
0:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:..\..\openssl-1.1.0f\ssl\record\ssl3_record.c:210:
|
|
|
|
Hi miniZ, After ~20 hours miner silently crashed, without any error. Only thing it had happened when miner was mining on dev fee server. On 1.3n+ or some beta version I noticed some openssl errors when miner connected dev fee pool, but miner didn't crash then. I enable logging now so I capture the error will report it here. (goto loop helps to restart the miner). [ 0d19h26m34s] S:10514/1 160(159.9)Sol/s 843(825.4)W [beam-eu.sparkpool.com]
0>GTX 1080 Ti ` 100% [61°C/51%] 18.71 I/s 38.2(37.5)Sol/s 191(179.9)W clk=1493MHz mclk=5899MHz Sol/W=0.21
1>GTX 1080 ` 100% [61°C/50%] 12.13 I/s 24.4(24.1)Sol/s 135(128.9)W clk=1506MHz mclk=5355MHz Sol/W=0.19
2>GTX 1080 ` 100% [60°C/49%]*12.16 I/s 24.1(24.3)Sol/s 127(129.0)W clk=1480MHz mclk=5355MHz Sol/W=0.19
3>GTX 1080 ` 100% [60°C/49%] 12.44 I/s 24.4(24.7)Sol/s 131(129.1)W clk=1366MHz mclk=5355MHz Sol/W=0.19
4>GTX 1080 ` 100% [55°C/45%] 12.42 I/s 24.1(24.5)Sol/s 132(129.2)W clk=1417MHz mclk=5355MHz Sol/W=0.19
5>GTX 1080 ` 100% [61°C/51%] 12.33 I/s 24.5(24.5)Sol/s 128(129.3)W clk=1379MHz mclk=5355MHz Sol/W=0.19
[ 0d19h26m44s] S:10517/1 159(159.9)Sol/s 828(825.1)W [fee.server]
0>GTX 1080 Ti ` 100% [61°C/51%]*18.70 I/s 38.0(37.5)Sol/s 180(179.9)W clk=1493MHz mclk=5899MHz Sol/W=0.21
1>GTX 1080 ` 100% [61°C/51%]*12.13 I/s 24.3(24.1)Sol/s 135(128.9)W clk=1442MHz mclk=5355MHz Sol/W=0.19
2>GTX 1080 ` 100% [60°C/49%] 12.16 I/s 24.1(24.3)Sol/s 123(129.0)W clk=1480MHz mclk=5355MHz Sol/W=0.19
3>GTX 1080 ` 100% [60°C/49%] 12.44 I/s 24.4(24.7)Sol/s 132(129.1)W clk=1404MHz mclk=5355MHz Sol/W=0.19
4>GTX 1080 ` 100% [55°C/45%] 12.42 I/s 24.3(24.6)Sol/s 129(129.2)W clk=1404MHz mclk=5355MHz Sol/W=0.19
5>GTX 1080 ` 100% [60°C/50%] 12.32 I/s 24.2(24.5)Sol/s 127(129.3)W clk=1392MHz mclk=5355MHz Sol/W=0.19
Waiting for 0 seconds, press a key to continue ...
************ miniZ v1.3n3 ************
Number of CUDA devices found: 6
miniZ,150,5[8:0:00]: Selecting GPU#0[0] GeForce GTX 1080 Ti
miniZ,150,5[2:0:00]: Selecting GPU#1[1] GeForce GTX 1080
miniZ,150,5[2:0:00]: Selecting GPU#2[2] GeForce GTX 1080
miniZ,150,5[2:0:00]: Selecting GPU#3[3] GeForce GTX 1080
miniZ,150,5[2:0:00]: Selecting GPU#4[4] GeForce GTX 1080
miniZ,150,5[2:0:00]: Selecting GPU#5[5] GeForce GTX 1080
Algo: EQ[150,5]
Pool#0: user[14794c3bea134979c40773495734d655e561224a4e5bc3600d81886457223e0c5.rig0]
server[beam-eu.sparkpool.com] port[2222] ssl[yes] pers[Beam-PoW]
Optimisation: oc2[0 1 2 3 4 5]
Temp. limit: [70°C]
[ 0d 0h 0m08s] S: 3/0 133(132.6)Sol/s 283(283.4)W [beam-eu.sparkpool.com]
0>GTX 1080 Ti ` 100% [56°C/46%]*16.53 I/s 30.5(30.5)Sol/s 66( 66.0)W clk=1695MHz mclk=5899MHz Sol/W=0.46
1>GTX 1080 ` 100% [53°C/42%] 10.58 I/s 21.3(21.3)Sol/s 43( 42.7)W clk=1607MHz mclk=5355MHz Sol/W=0.50
2>GTX 1080 ` 100% [53°C/44%] 10.63 I/s 18.4(18.4)Sol/s 45( 45.3)W clk=1607MHz mclk=5355MHz Sol/W=0.41
3>GTX 1080 ` 100% [52°C/45%]*10.85 I/s 21.0(21.0)Sol/s 43( 43.0)W clk=1607MHz mclk=5355MHz Sol/W=0.49
4>GTX 1080 ` 100% [48°C/43%] 10.78 I/s 18.7(18.7)Sol/s 42( 41.7)W clk=1607MHz mclk=5355MHz Sol/W=0.45
5>GTX 1080 ` 100% [53°C/45%] 10.55 I/s 18.5(18.5)Sol/s 45( 44.8)W clk=1607MHz mclk=5355MHz Sol/W=0.41
Best regards, |
|
|
|
|
One question @miniZ,
Do you have implemented some anti-hacking solution, as Gminer released "optimized" miner for 150_5?
He (or they) become famous as thieves of other miner code, probably they spend some time reverse engineering competitors miners and stealing ideas.
They released beta now which improves 150_5, and previously they updated kernel months ago.
So be aware.
PS: I like your miner, especially --oc2 option can be handy when power limit needs to go down through summer.
Also I noticed that "templimit" option isn't readed from config file.
|
|
|
|
 v1.3n+ and v1.3n++ (beta build, Apr 28 2019 12:28:20) CUDA 10 versions doesn't work on sparkpool, see picture above. Sparkpool is displaying that there are too many rejected shares, but it's not reporting it back to miner, so in miner it looks good, but on poolside >95% of shares are rejected (or stales). Then I left it to mine on leafpool and it keeps mining fine for more than 8 hours. Only thing I noticed is that at some point it hits 100% CPU usage and stays like that, I need to investigate this more. CPU: Celeron G3930 (@2.90 GHzm 2C/2T) RAM: 4 GB Virtual Mem.: 64 GB GPUs: 1x 1080ti MSI Gaming 5x 1080 inno3d twin X2 OS: Windows Server 2016 (version 1607, OS Build 14393.2273) Nvidia driver: 419.17 (CUDA 10.10) MSI Afterburner (for OC): 4.6.0 -> noting this as it can be cause of 100% CPU usage, because on 1080ti fanspeed readings in miniZ console becomes 0%, maybe there are conflict between querying Nvidia-SMI stats from miner and Afterburner, idk. |
|
|
|
because PM works once in a day have to write answer here: looks like beta2-version fixed connections bug for me. But miner doesn't pausing process while no connect.
Yes, it pause the mining and then when connection is restored it continues mining (on failover pool if at the moment try connect to it) 1. normal mining power consumption (954 W) 2. cable (connection lost) power consumption (311 W) after around ~1 minute (miner don't suspend mining at the moment when connection is lost, which is OK) 3. message in miner, after LAN cable is pluged back mining resumes on retrying pool (cloud be failover one) https://imgur.com/a/QMdSZrn |
|
|
|
I noticed that miner doesn't stop mining threads when connection to pool stratum is lost, it's tries to reconnect but until then mining is not not suspended.
This is ok when disconnects are short, but when they are longer this is bad.
Pls. implement this behavior, it would be nice to have config param to specify disconnect timeouts, and then to stop mining even exit the miner.
Thx. I started testing this miner on MTP, and I'm still looking for optimal intensity and grid size for 1080 and 1080ti.
For now I like it's stability and constant GPU/POWER usage.
Hi, thanks for your report.- I'm working on this issue already. You can specify a backup/fail-over pool until I found the bug and release a fix. Finding the sweet-spot for gridsize is somewhat tricky since all high values are very close together. I made the experience that from a certain value for gs the hash-rates starts high, but continue to drop the shortly after. Thanks for your support. Hi I specified failover pool, that's working fine. But I mean that when Internet connection is cut to rig, like when ISP went down, or when you unplug LAN cable from rig (to simulate loss of connectivity). Miner just show that connection to stratum is lost and whole time Power Consumption/GPU Usage is same like mining regulary, but now is wasting power. I wouldn't notice this flaw if my ISP didn't started having problems recent days, but they fixed their network infrastructure after few days. |
|
|
|
15.3.0 not working stable for me. Getting this error after random amount of time mining, PL% and OC settings are not high and it's super stable on other version. [INFO] CUDA error DRIVER: '700' in func 'bminer::cuckoo::CuckooStyleSolverCudaBase::CopyEdges' line 215
[FATA] Fatal cuda error in GPU 5. Terminate soon... And then it just hangs, can't even restart the Windows regular way. OS: Windows Server 2016 Drivers: 419.17 1080ti PL 76% Core +160 Mem +380 1080 (one on which error happens) PL 76% Core +165 Mem +380 |
|
|
|
|
