miniZv2.3c Equihash144,5 125,4 210,9 150,5 192,7 Beam ProgPoW Ethash CFX KLS PYI

[miniZ]

Guys, Why do I have 0 hashrate?

Code:

miniZ<144,5s>[06:0:00:6747]: Selecting GPU#0[0] GeForce RTX 2060 SUPER
[ 0d 0h 0m06s] 0>RTX 2060 SUPER ` 100% [45°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  42( 42.2)W clk=1470MHz mclk=6801MHz Sol/W=0.00
[ 0d 0h 0m10s] 0>RTX 2060 SUPER ` 100% [45°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  42( 42.2)W clk=1470MHz mclk=6801MHz Sol/W=0.00
[ 0d 0h 0m20s] 0>RTX 2060 SUPER ` 100% [45°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  42( 41.5)W clk=1470MHz mclk=6801MHz Sol/W=0.00

I tried to use miniZ on different machines and got the same result.
Thanks.

Hi Xadja,
Could you tell us what algo are you mining, and the command line you are using?
Also, could you paste here the start of the log? We mean the log information that miniZ prints, before it starts mining.
Maybe we'll be able to understand what is going on then.
Thanks!
Cheers

[1715427253]

1715427253

[1715427253]

1715427253

[1715427253]

1715427253

[1715427253]

1715427253

[1715427253]

1715427253

[1715427253]

1715427253

[Xadja]

Hi Xadja,
Could you tell us what algo are you mining, and the command line you are using?
Also, could you paste here the start of the log? We mean the log information that miniZ prints, before it starts mining.
Maybe we'll be able to understand what is going on then.
Thanks!
Cheers

Thank you for the answer!

Here is command line:

Code:

.\miniZ.exe --url=28acc5ea73280ffea8a8d2a61358f7c500c0c9eb132b0b3bb15eeb63f52fea65a3e@beam-eu.leafpool.com:3333 --par=beam3 --log --ocX

Here is log:

Code:

************ miniZ v1.6v5 ************
Number of CUDA[10.0] devices found: 1
Algo:		EQ[beam3] 
Pool#0: 	user[28acc5ea73280ffea8a8d2a61358f7c500c0c9eb132b0b3bb15eeb63f52fea65a3e]
		server[beam-eu.leafpool.com] port[3333] ssl[no] pers[Beam-PoW]
Telemetry:	[http://localhost:20000]
Logging:: 	file[miniZ.log] period[10] delay[0]
Optimisation:	ocX[0] 

[miniZ]

Thank you for the answer!

Here is command line:

Code:

.\miniZ.exe --url=28acc5ea73280ffea8a8d2a61358f7c500c0c9eb132b0b3bb15eeb63f52fea65a3e@beam-eu.leafpool.com:3333 --par=beam3 --log --ocX

Hi Xadja,
To mine Beam to LeafPool you need to indicate that it is a ssl connection port. Most (if not all) Beam pools use ssl ports.

In this case, the command line needs 'to know' that the port is ssl:

Code:

.\miniZ.exe --url=ssl://28acc5ea73280ffea8a8d2a61358f7c500c0c9eb132b0b3bb15eeb63f52fea65a3e@beam-eu.leafpool.com:3333 --par=beam3 --log --ocX

You'll see that in the log now appears ssl[yes]. It should work now.

Let us know if this solved your issue.
Thanks for for the feedback and for using miniZ.
Cheers

[Xadja]

Yes, it works fine now. Thanks!

[mirny]

no github, or sourcecode?
i need to compile for cuda 9.1

[miniZ]

no github, or sourcecode?
i need to compile for cuda 9.1

Hi mirny,
miniZ is not an opensource project.
If you cannot upgrade the NVIDIA driver, you can use CUDA 8 version.
It should perform as well as a 9.1 version.
Cheers

[Quentin0208]

Hello,

I have big problems with MiniZ since I changed algo 144.5 to 192.7.

Lots of invalid shares and the miner reboots after a while. In 8 times last night he rebooted 8x.

I am on SimpleMiningOS and also on EasyMiningOS, the same problem is present on both OS and is happening to me on all my Nvidia 1080ti 1070gtx 2070rtx 2080ti rigs.

I have asked several people to mine the same algo and they also suffer from invalid shares.

I was advised to decrease the OC but it didn't have much effect. I still have invalid shares leaving the base frequencies and decreasing the watts.

My question is therefore, as this algo is used very little is that there is always an optimization concerning this algo. I had to go back to Gminer, I lost all 60sol but I have no invalid or no reboot of the miner.

Thank you.

[miniZ]

Hello,

I have big problems with MiniZ since I changed algo 144.5 to 192.7.

Lots of invalid shares and the miner reboots after a while. In 8 times last night he rebooted 8x.

I am on SimpleMiningOS and also on EasyMiningOS, the same problem is present on both OS and is happening to me on all my Nvidia 1080ti 1070gtx 2070rtx 2080ti rigs.

I have asked several people to mine the same algo and they also suffer from invalid shares.

I was advised to decrease the OC but it didn't have much effect. I still have invalid shares leaving the base frequencies and decreasing the watts.

My question is therefore, as this algo is used very little is that there is always an optimization concerning this algo. I had to go back to Gminer, I lost all 60sol but I have no invalid or no reboot of the miner.

Thank you.

Hi Quentin0208,
Thanks for the feedback.
We did not manage to reproduce your issue. Could you give us some more information?
 
Which miniZ version are you using?
Also, could you paste here your command line, and the beginning of the log when the miner starts?

We'll try to replicate the behaviour.
Cheers

[Quentin0208]

Hello,

I have big problems with MiniZ since I changed algo 144.5 to 192.7.

Lots of invalid shares and the miner reboots after a while. In 8 times last night he rebooted 8x.

I am on SimpleMiningOS and also on EasyMiningOS, the same problem is present on both OS and is happening to me on all my Nvidia 1080ti 1070gtx 2070rtx 2080ti rigs.

I have asked several people to mine the same algo and they also suffer from invalid shares.

I was advised to decrease the OC but it didn't have much effect. I still have invalid shares leaving the base frequencies and decreasing the watts.

My question is therefore, as this algo is used very little is that there is always an optimization concerning this algo. I had to go back to Gminer, I lost all 60sol but I have no invalid or no reboot of the miner.

Thank you.

Hi Quentin0208,
Thanks for the feedback.
We did not manage to reproduce your issue. Could you give us some more information?
 
Which miniZ version are you using?
Also, could you paste here your command line, and the beginning of the log when the miner starts?

We'll try to replicate the behaviour.
Cheers

Hi, thank you for your reply. Here is the command line for launching the miner :

--url=v1YorRJQhCC9tQN9qbW4svq8nwjUjzW1cRe.2070RTX@vidulum.dapool.io:3377 --par=192,7 --pers=EquivPoW -p x --intensity=100 --latency  --show-shares  --templimit=75 --cleanjobs --ocX

And here is the line which contains the error and which leads to a reboot :

[ 0d13h26m00s] S:4527/61 247(247.7)Sol/s 891(888.9)W- 100ms
0_RTX 2070 `98.6% [69C/86%]*19.63 I/s 38.3(39.5)Sol/s 149(148.6)W clk=1560MHz mclk=6550MHz Sol/W=0.27
1_RTX 2070 `98.9% [70C/86%] 20.62 I/s 41.8(41.5)Sol/s 148(148.1)W clk=1620MHz mclk=6550MHz Sol/W=0.28
2_RTX 2070 `99.1% [62C/85%] 20.39 I/s 40.8(40.9)Sol/s 149(148.5)W clk=1590MHz mclk=6550MHz Sol/W=0.28
3_RTX 2070 `98.1% [68C/85%] 21.22 I/s 42.5(42.5)Sol/s 149(148.1)W clk=1725MHz mclk=6550MHz Sol/W=0.29
4_RTX 2070 `98.6% [67C/85%] 21.05 I/s 41.7(42.0)Sol/s 148(147.8)W clk=1710MHz mclk=6550MHz Sol/W=0.28
5_RTX 2070 `98.8% [66C/84%] 20.65 I/s 40.9(41.4)Sol/s 148(148.2)W clk=1665MHz mclk=6550MHz Sol/W=0.28
/root/xminer.sh: line 174: 4611 Segmentation fault $minerSudo /root/miner/$MINER_PKG_NAME_/_$MINER_FILE $MINER_OPTIONS_GO
Miner ended or crashed. Restarting miner in 30 seconds...

And here the percentage of invalid shares per graphics card

https://i.imgur.com/Cs0dKTy.jpg

++

[somaton]

I think you will not have rejects after you remove --cleanjobs. Who was that "smart" person that said you must have it there without testing first?

[Quentin0208]

I think you will not have rejects after you remove --cleanjobs. Who was that "smart" person that said you must have it there without testing first?

The command before did not include --cleanjobs and it was the same result, I had put this command precisely hoping that it will change something.

[miniZ]

I think you will not have rejects after you remove --cleanjobs. Who was that "smart" person that said you must have it there without testing first?

The command before did not include --cleanjobs and it was the same result, I had put this command precisely hoping that it will change something.

Hi Quentin0208,
Thanks for the information.

As somaton suggested, cleanjobs only works with a few pools, in general is best not to use it.

We could see a few invalid shares on daPool, not many though. It seems not to happen on other pools.
We contacted the pool already to check if this is a real issue or not (if these shares are invalid indeed).

We are currently checking the other issue that you seem to be having with the miner exiting. We assume that you are mining with the latest version, miniZ v1.6v5. Do you confirm this?

Cheers

[Quentin0208]

I think you will not have rejects after you remove --cleanjobs. Who was that "smart" person that said you must have it there without testing first?

The command before did not include --cleanjobs and it was the same result, I had put this command precisely hoping that it will change something.

Hi Quentin0208,
Thanks for the information.

As somaton suggested, cleanjobs only works with a few pools, in general is best not to use it.

We could see a few invalid shares on daPool, not many though. It seems not to happen on other pools.
We contacted the pool already to check if this is a real issue or not (if these shares are invalid indeed).

We are currently checking the other issue that you seem to be having with the miner exiting. We assume that you are mining with the latest version, miniZ v1.6v5. Do you confirm this?

Cheers

Yes I confirm the version.

https://i.imgur.com/8FUK2op.jpg

[miniZ]

Yes I confirm the version.

Hi Quentin0208,
Thank you for your reply!

We can confirm that the shares are in fact stale shares (shares that are submitted for an expired job ID).
On the pool side this will not be a problem, for you it will be like the miner is ~0.8-1.6% slower.
This can be related to connection latency, but maybe we can try to improve the miner on this.

Concerning the miner exiting, so far we have been unable to reproduce the issue on the latest version.
We'll keep checking this.
Cheers

[Quentin0208]

Yes I confirm the version.

Hi Quentin0208,
Thank you for your reply!

We can confirm that the shares are in fact stale shares (shares that are submitted for an expired job ID).
On the pool side this will not be a problem, for you it will be like the miner is ~0.8-1.6% slower.
This can be related to connection latency, but maybe we can try to improve the miner on this.

Concerning the miner exiting, so far we have been unable to reproduce the issue on the latest version.
We'll keep checking this.
Cheers

Ok so, to give some feedback and following the line of thought you gave me I changed the pool altogether.
Indeed and since that time I have had no invalid shares or reboot of MiniZ. I wonder if, precisely, it is not the invalid ones that give the information to the reboot miner?

Anyway, here are my new stats on the new pool and it works perfectly, thank you for your information.

[miniZ]

Hi everyone,

A new miniZ version v1.6v6 is out with improved stability in all algorithms.

Please find miniZ version v1.6v6 @ Download page.

Changelog:
 * Improved stability in all algorithms.
 * Added --stale=n option to help deal with high number of stale shares (default n=100).
    Increasing n will allow higher number of stale shares but may be beneficial to performance. Decrease n if you have too many stale shares.
 * Fixed invalid shares while mining beam.
 * Fixed stale shares that were misidentified as invalid on daPool.
 * Smarter check when ssl/tls mining if user does not declare it explicitly on the command line.
 * Other minor bug fixes.

*** Thank you for all the feedback! ***

Download miniZ version v1.6v6 here.
For additional information check the Usage or the FAQ pages.

Happy mining!

[miniZ]

Ok so, to give some feedback and following the line of thought you gave me I changed the pool altogether.
Indeed and since that time I have had no invalid shares or reboot of MiniZ. I wonder if, precisely, it is not the invalid ones that give the information to the reboot miner?

Anyway, here are my new stats on the new pool and it works perfectly, thank you for your information.

Hi Quentin0208,
Thank you for your feedback.
The issue you faced when mining with daPool should be fixed with the new version.
Hopefully any random crashes that you may encounter on other pools should have been solved as well.
Let us know if it worked for you.
Cheers

[somaton]

Upgraded to v1.6v6 and tried ocX with --mode for first time.

this is what i have: [TRACE  ] GPU[2]: Tune finished: mode=11 speed=13.67 max:16.197

1. Looking at this text line, i see that mode 11 is slow, because it is giving only 13,67, but some other unknown/unmentioned mode is giving 13,67. Why you dont show the mode number that was the fastest one? Now i have to scrool to see which mode is in question.
2. When looking at miniz.cz FAQ, you say that --mode 8 or --mode=8 both are correct, BUT when i put "--mode=11 --mode1=5" miniz will not start, but will start with "--mode 11 --mode1 5". Btw, there is small typo in HTML, tag </span.

Beamv3 is better with this version, less rejects, but still not 0. Thanks.

UPDATE:

ok, now i see that it is not that simple. Problems with explanations again...
with other rig that have 1080ti's only, now i understood how it is working.

[TRACE  ] GPU[1]: switch mode 7 -> mode 8, speed=11.98 max:15.477[09]

and this

[TRACE  ] GPU[1]: Tune finished: mode=9 speed=10.55 max:15.477

miniz actually is showing which mode is fastest in tune mode, but it is shown in different way when it is done. If it is done, and fastest mode is shown (Tune finished), why speed of some other slow mode is shown? Or if you want to show speed of last tested mode in "tune finished" string, why its number is not shown?

back again to strings when miniz is switching modes:

switch mode 7 -> mode 8, speed=11.98 max:15.477[09]

i think MUCH more logic string will look like this:

switch mode 7, speed=11.98 -> mode 8, max:15.477[09]

I hope you do understand what i mean, even such small things do have some meaning.

[miniZ]

Upgraded to v1.6v6 and tried ocX with --mode for first time.

this is what i have: [TRACE  ] GPU[2]: Tune finished: mode=11 speed=13.67 max:16.197

1. Looking at this text line, i see that mode 11 is slow, because it is giving only 13,67, but some other unknown/unmentioned mode is giving 13,67. Why you dont show the mode number that was the fastest one? Now i have to scrool to see which mode is in question.
2. When looking at miniz.cz FAQ, you say that --mode 8 or --mode=8 both are correct, BUT when i put "--mode=11 --mode1=5" miniz will not start, but will start with "--mode 11 --mode1 5". Btw, there is small typo in HTML, tag </span.

Beamv3 is better with this version, less rejects, but still not 0. Thanks.

I hope you do understand what i mean, even such small things do have some meaning.

Hi somaton,

1. We get your point and we understand that the way the log/speed report is done at the moment can be confusing. We'll improve this for the next version. Meanwhile, maybe try using --show-mode, it will help you to keep track of the kernel mode being used. It may be useful during switching.

2. When using --mode you can use '=' but when when using mode applied to a specific GPU --modeX the '=' cannot be used. We'll modify the FAQ with better explanation regarding the use of --mode.

Thanks a lot for the feedback!
Cheers

[john1010]

I hope ypu will also develop for AMD cards, and kindly look at the other side of the 2 miner here like Claymore and Phoenix and fix the flaw of this 2 miner in your development, we don't care about the mining dev fee.