Search content
Sort by
Showing 20 of 31 results by hogwash.89m
@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.
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.
Re: miniZ, fast & friendly Equihash 144,5 150,5,3 125,4 192,7 210,9 150,5 96,5 miner
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
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.5s version without issue, only there was one crash, and then for like 15 hours it was OK again.
Quote
[ 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
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.5t 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.
Re: miniZ, fast & friendly Equihash 144,5 150,5,3 125,4 192,7 210,9 150,5 96,5 miner
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.
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.
Re: GMiner v1.45 Equihash(BEAM, VDS, BTG)/CuckooCycle(AE, SWAP, GRIN)
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).
Re: miniZ, a new fast and friendly Equihash <144,5><150,5><192,7><96,5> Cuda miner.
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.
Same settings for all cards.
PL 72%
core +180
mem +360
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.
Quote
[ 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
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
Re: GMiner v1.41 Equihash(BEAM, BTG)/CuckooCycle(AE, SWAP/GRIN29)
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
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
Re: miniZ, a new fast and friendly Equihash <144,5><150,5><192,7><96,5> Cuda miner.
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
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
@miniZ
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) :
Code:
PL 72%
Core +180
Mem +340
Core +180
Mem +340
Currently, when miner crashes, for example with these errors:
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?
Code:
[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
[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?
@ltxminer
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.
Code:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"DontShowUI"=dword:00000001
[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
Re: miniZ, a new fast and friendly Equihash <144,5><150,5><192,7><96,5> Cuda miner.
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.
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?
Spending some development time on new ZelHash algo (new ZEL antiFPGA/ASIC algo) would be nice, as it's promising coin.
Re: miniZ, a new fast and friendly Equihash <144,5><150,5><192,7><96,5> Cuda miner.
Error when mining on dev [fee.server].
Hi hogwash.89m,Code:
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:
[ 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:
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.
Re: miniZ, a new fast and friendly Equihash <144,5><150,5><192,7><96,5> Cuda miner.
Error when mining on dev [fee.server].
Code:
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:
[ 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:
Re: miniZ, a new fast and friendly Equihash <144,5><150,5><192,7><96,5> Cuda miner.
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).
Best regards,
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).
Code:
[ 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
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,
Re: miniZ, a new fast and friendly Equihash <144,5><150,5><192,7><96,5> Cuda miner.
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.
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.
Re: miniZ, a new fast and friendly Equihash <144,5><150,5><192,7><96,5> Cuda miner.
https://i.imgur.com/OMGwSrh.png
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.
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.
Re: TT-Miner 2.2.1: ProgPoW, MTP, LYRA2V3, UBQHASH, MYR-GR Win/cuda9.2/10.0/10.1
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
Off topic, but what is the power-monitoring device you have plugged in in your last picture in your link?
@dkmontague you asked about power monitoring device.
In last picture it's just desktop with TT-Miner and Afterburner (Watts in TT-Miner are readings from Nvidia NVLM API, software reading).
And device in power outlet is I think this one, EU socket type:
https://www.aliexpress.com/item/230V-50Hz-Power-Meter-Energy-Monitor-EU-Watt-Volt-Amp-Frequency-Monitor-Analyzer-Cumulative-Kilowatt-Hour/32817695107.html
(PS: I think it can be found cheaper on other shops)
Or this one US plug type:
https://www.amazon.com/FLOUREON-Electricity-Monitor-Voltage-Measuring/dp/B07B3VQBZH
All the best,
Re: TT-Miner 2.2.1: ProgPoW, MTP, LYRA2V3, UBQHASH, MYR-GR Win/cuda9.2/10.0/10.1
@TrailingStop Hi,
One of my friend has a problem with TT-Miner 2.2.2 beta2, he doesn't try older versions but probably problem is also on every version.
He is getting error when trying to mine MTP with 8 Nvidia cards, default -intensity 15.
We didn't find limit for number of GPUs in README guide.
OS: Win 10
Driver: 419.67
RAM: 4 GB
Virtual Mem.: 99 GB
GPUs:
6 x 1070 8GB
2 x 1070ti 8GB
Running with -a MTP-101
And these are settings for Virtual Memory (Initial size: 99000 MB, Maximum size 99000 MB, Currently allcated: 99000 MB
https://cdn.discordapp.com/attachments/379391607406985218/566652780631293992/unknown.png
Thx. for support.
One of my friend has a problem with TT-Miner 2.2.2 beta2, he doesn't try older versions but probably problem is also on every version.
He is getting error when trying to mine MTP with 8 Nvidia cards, default -intensity 15.
We didn't find limit for number of GPUs in README guide.
OS: Win 10
Driver: 419.67
RAM: 4 GB
Virtual Mem.: 99 GB
GPUs:
6 x 1070 8GB
2 x 1070ti 8GB
Running with -a MTP-101
Quote
CudaError: 2
Not enough memory to run algo. GPU disabled.(0/1)
Plese check if your Virtual Memory settings....
https://cdn.discordapp.com/attachments/379391607406985218/566651306886955008/unknown.pngNot enough memory to run algo. GPU disabled.(0/1)
Plese check if your Virtual Memory settings....
And these are settings for Virtual Memory (Initial size: 99000 MB, Maximum size 99000 MB, Currently allcated: 99000 MB
https://cdn.discordapp.com/attachments/379391607406985218/566652780631293992/unknown.png
Thx. for support.
Re: TT-Miner 2.2.1: ProgPoW, MTP, LYRA2V3, UBQHASH, MYR-GR Win/cuda9.2/10.0/10.1
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
Re: TT-Miner 2.2.1: ProgPoW, MTP, LYRA2V3, UBQHASH, MYR-GR Win/cuda9.2/10.0/10.1
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.
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.
Re: GMiner CUDA Equihash 96,5/144,5/150,5(BEAM)/192,7/210,9 Miner v1.16
Hi Zminer777,
I'm experiencing errors mining 150,5 (BEAM).
I thought that memory overclock was causing it, but reverting to default errors still happens.
Also I needed to turn off watchdog, because with it miner just hangs, I can't kill the process only restart helps.
GPUs are 1080ti and 1080
driver version 417.58 (CUDA 10)
Windows Server 2016
Also I noticed that 1080ti how now stabilized GPU Power (voltage) it's like on other Equihash solvers, but 1080 still have quite varying.
I assume that 1080 is not much optmized because it has even same hashrate as 1070 and in every other solver 1080 has higher compred to 1070.
(see the screenshot, GPU0 is 1080ti rest are 1080).
https://i.imgur.com/yqETSbE.png
I'm experiencing errors mining 150,5 (BEAM).
I thought that memory overclock was causing it, but reverting to default errors still happens.
Also I needed to turn off watchdog, because with it miner just hangs, I can't kill the process only restart helps.
GPUs are 1080ti and 1080
driver version 417.58 (CUDA 10)
Windows Server 2016
Quote
22:48:02 Error on GPU3: an illegal memory access was encountered
22:48:02 Stopped Mining on GPU0
22:48:02 Stopped Mining on GPU1
22:48:02 Stopped Mining on GPU2
22:48:02 Stopped Mining on GPU3
22:48:02 Stopped Mining on GPU4
22:48:02 Stopped Mining on GPU5
22:48:02 Stopped Mining on GPU0
22:48:02 Stopped Mining on GPU1
22:48:02 Stopped Mining on GPU2
22:48:02 Stopped Mining on GPU3
22:48:02 Stopped Mining on GPU4
22:48:02 Stopped Mining on GPU5
Also I noticed that 1080ti how now stabilized GPU Power (voltage) it's like on other Equihash solvers, but 1080 still have quite varying.
I assume that 1080 is not much optmized because it has even same hashrate as 1070 and in every other solver 1080 has higher compred to 1070.
(see the screenshot, GPU0 is 1080ti rest are 1080).
https://i.imgur.com/yqETSbE.png
