Good day, miniZ!
I am running v2 miniZ for some time now, runs like a top without any issues on Win10 running variety of green cards on 2 different rigs mining BeamhashIII. I recently got a 2080TI and needed to D/L miniZ v2 for a new rig and no can do because it's gone? So, I D/L v1.6w and got up and running but cannot run this card below 81% power? It crashes and Windoze takes over to announce that "stop code :Video TDR failure What failed: nvlddmkm.sys" shuts me down and restarts my computer. After much experimentation with various settings, I am currently running straight and true at 81% power (~920mv) 0 core/-500 memory, 242 watts with 42.3 hashes. Not bad, but I want to get the power lower. I will give up a hash or two to get this thing down ~200. Any idea what's up? Sure wish I could run it on v2 I think, but making big changes to other rigs for 40 watts is more than I care to do. Anywhere to score a D/L of v2 to try? Thanks for any help and your fine product.
Topic: miniZ v2.0a Equihash 144,5 125,4 210,9 150,5 192,7 BeamHash3 ProgPoW Ethash CFX - page 21. (Read 60004 times)
September 28, 2020, 09:40:29 AM
September 24, 2020, 11:01:50 AM
Is it possible to mine BeamHash III on GTX 1050 2GB under Windows 7?
I get an error:
miniZ requires at least 1930MB to run, but only has 1913MB
So sad, what's just 17 mb lacks.
Whether there is a possibility to reduce Win7 GPU memory usage? Default theme, no wallpaper, 1024 resolution already installed. Maybe downgrade to some old nvidia drivers?
Or the only possibility is to migrate to Linux?
Hi bourbonmorning, I get an error:
miniZ requires at least 1930MB to run, but only has 1913MB
So sad, what's just 17 mb lacks.
Whether there is a possibility to reduce Win7 GPU memory usage? Default theme, no wallpaper, 1024 resolution already installed. Maybe downgrade to some old nvidia drivers?
Or the only possibility is to migrate to Linux?
Thanks for your message.
We'll see if we can shrink it a little. However, keep in mind that this will decrease performance.
We do not think that older drivers could help. But if you try this, do let us know if it does.
Cheers
September 23, 2020, 03:42:13 PM
Is it possible to mine BeamHash III on GTX 1050 2GB under Windows 7?
I get an error:
miniZ requires at least 1930MB to run, but only has 1913MB
So sad, what's just 17 mb lacks.
Whether there is a possibility to reduce Win7 GPU memory usage? Default theme, no wallpaper, 1024 resolution already installed. Maybe downgrade to some old nvidia drivers?
Or the only possibility is to migrate to Linux?
I get an error:
miniZ requires at least 1930MB to run, but only has 1913MB
So sad, what's just 17 mb lacks.
Whether there is a possibility to reduce Win7 GPU memory usage? Default theme, no wallpaper, 1024 resolution already installed. Maybe downgrade to some old nvidia drivers?
Or the only possibility is to migrate to Linux?
September 18, 2020, 08:41:17 AM
Hi everyone,
miniZ version v1.6w is out with major improvements in 150,5 algorithm – Grimm, Defis, Litecash!
Please find miniZ version v1.6w @ Download page.
Changelog:
- 150,5 major improvements: 2-20%, depending on GPU. Turing GPUs have the largest improvements.
- Added ocX table to telemetry. Current mode shown in blue, the best in red.
- ocX best mode can be saved to configuration file. (See FAQ)
- In console, ocX log is more clearly shown.
- Added comand line options: ocXreset - reset stats when finishes ocX; ocXsamples increase/decrease samples in ocX search (default 300).
- You can already write --mode1=5 to select a mode to specific GPU (before you could not use '=').
*** Thank you for all the feedback! ***
Download miniZ version v1.6w here.
For additional information check the Usage or the FAQ pages.
Happy mining!
September 01, 2020, 10:14:40 AM
Has this been implemented in 1.6v6? I cannot find anything documented.
We did not manage to add that possibility. Sorry about this.
We are considering to write the best mode to the configuration file. At the moment it seems to be the best way to implement this.
Thanks for the reminder!
Cheers
Thanks for the feedback!
August 31, 2020, 06:16:33 PM
Has this been implemented in 1.6v6? I cannot find anything documented.
We did not manage to add that possibility. Sorry about this.
We are considering to write the best mode to the configuration file. At the moment it seems to be the best way to implement this.
Thanks for the reminder!
Cheers
August 31, 2020, 06:14:29 PM
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. 
Hi john1010,thank you for your message.
At the moment we are working on algorithm improvements, and general optimisations, after this we will think about it.
Cheers
August 31, 2020, 12:58:50 AM
Probably the best solution:
-OCx will do the optimization, then store the best found parameters somewhere (registry / file)
On next start miniZ should read and auto-apply the stored values (maybe enable this with an optional parameter)
Thanks for the suggestion.
We'll work on something for the next version.
Cheers
Has this been implemented in 1.6v6? I cannot find anything documented.
August 30, 2020, 08:51:10 PM
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.
August 30, 2020, 08:24:59 PM
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
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.
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
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
August 30, 2020, 04:23:09 PM
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
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.
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
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.
August 29, 2020, 07:54:36 PM
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,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.
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
August 29, 2020, 07:36:27 PM
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!
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!
August 21, 2020, 02:55:40 AM
Yes I confirm the version.
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.
August 20, 2020, 08:06:16 PM
Yes I confirm the version.
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
August 20, 2020, 12:08:33 PM
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.
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
August 20, 2020, 08:20:51 AM
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.
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
August 20, 2020, 02:50:21 AM
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.
August 19, 2020, 03:37:48 PM
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?
August 19, 2020, 02:38:44 PM
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, 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.
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
++
Jump to: