Topic: [CMD] FarmWatchBot Ewbf, Claymore, Bminer, Dstm, CC, Eth, CastXMR, Phoenix - page 11. (Read 37024 times)

can i use this script on mining zcl?

p.s. it would be great if you could make a video tutorial

im looking for something like this :

https://bitcointalksearch.org/topic/unattended-rig-automatic-overclockingfans-controlmail-sendinghw-safe-guarded-134473

Automatic downclocking of each GPUs  ( basing on the GPU temperature, target temperature, error reported from miner or hw )

but this script look be old & made for ATI & not for nvidia...

Today version 1.8.5 released!

Changelog:

• Added error handlers for Dstm miner.
• Added a command to switch between miners using the Telegram Bot.
• Added option to the configuration file to disable share time checking.
• Ability to change the name of the configuration file, log file.
• Optimization of the code, correction of small errors.

Cпиcoк измeнeний:

• Дoбaвлeны oбpaбoтчики oшибoк для Dstm мaйнepa.
• Дoбaвлeнa кoммaндa для пepeключeния мeждy мaйнepaми пpи пoмoщи Telegram бoтa.
• Дoбaвлeнa oпция в фaйл кoнфигypaции для oтключeния пpoвepки вpeмeни шapы.
• Boзмoжнocть измeнeния нaзвaния фaйлa кoнфигypaции, фaйлa лoгoв.
• Oптимизaция кoдa, иcпpaвлeниe мeлкиx oшибoк.

Ewbf 0.3.4 version
Dstm 0.5.7 version
Claymore 12.6 version (Equihash)
Claymore 10.2 version (CryptoNote)
Claymore 10.2 version (Dagger-Hashimoto)

Hello. Thx.
Sorry but it is hard to help you, every (and each) card have individual OC settings, you just need to find them. By increasing values from default 10 by 10 and 1 by 1. It is possible to use nvidia inspector but it is hard to indicate values for all users. So it is individual problem and must be resolved only by you. Same with temperatures, it depends where you stay your machines. You need to think about fans and coolers. It is standart problems of all miners. But on this forum you can find good advices!

thank's you for your script ,usefull here.

i got few probleme with my rig ,

im newbie here,  got ring since less 3 weeks
and using your script since 1 week ,

and i have probleme actually ,no probleme about reboot & restart minning Zcash.
but i have 1 card bad.

i see you spy card Temp for slow down work to heat less card.
but here , card look crash or hashrate down alot

your script ,restart card/computer but card crash again few hours later.

can you look about Overclocking control ?  ( Underclocking )

what i ask ,when a card crash , just slow down overlocking of the poor card to get it stable.

actually im using afterburner but not good to do this.
but i think it's possible with nvidia inspector.

i will look to do it ,but im 0 in script ( i used basic on cpc6128 , 25y ago but .... im 0 in bash but it look similar )

i dont ask for overlocking , it's for underclocking ,when summer comme T°  up ....
 
same get zm crashed , i got windows error message about zm error  but zm windows is open
and no reaction from script like all work fine

but no more minning

anyone know a good pool low fee to get email when rig dont mine anymore or too mutch slower ?

Thx


Please explain more. What OS ar you using, what miner exactly. Thx!


After holidays will be some updates. Im working to add new miners and functionality. Thx!

Any plans to add ability to use something like nemosminer for multi-algo?  I'd be interested to discuss a donation for this 

Hello there

i just preapred some new rigs with 4.4.2 MSIA. The script seems to get frozen - config.bat loaded... then 120 sec to start MSIA - but nothing happens.

If i kill the process from startup and then start manually, press space to skip - launches ok.

Is it MSIA new version fault or the script?

have seen those hangs also some time on previous 20 beta version.

BR

Hi Acre, billion thanks for this awesome work.

wanted to ask you if i can use the eth-claymore script while dual mining (ex. eth+dcr). i did try but i got errors/miner restars due to 2nd coin problem. what should the command line order be?

thanks again and keep up the good work
R


Never mind, got it to work

Use 24 hours format.

I get these showing up in Miner-autorun: "Invalid number.  Numeric constants are either decimal (17), hexadecimal (0x11), or octal (021)."

These stats are displaying wrong in Miner-autorun: "Average Sol/s: 0 Last Sol/s: 67C" . A bug in this version? I didn't try earlier versions.

Dstm 0.5.7 and Autorun 1.8.3

Edited: Changing the dots to colons in my windows date and time format fixed this, as in to 18:12:00 instead of 18.12.00 .

Thanks Acrefawn, great job with the program!

Today version 1.8.3 released!
Changelog:

• Fixed bug with temperature error.
• The screenshot function is added during the miner error.

Ewbf 0.3.4 version
Dstm 0.5.7 version
Claymore 12.6 version (Equihash)
Claymore 10.2 version (CryptoNote)
Claymore 10.2 version (Dagger-Hashimoto)

Hello! Thank you for your time, testing and this response. About average hashrate and temperatures will think and post some updates little bit later. ATM bussy little bit.
Contact me in Telegram please.

Hi Acrefawn,

Thanks for the update, looks good.

Since the update I have not experienced the issue where too many cards were detected. Well done.

Low Hashrate detection
In response to nuisance restarts from low hashrate, I have reduced my input for "average" hashrate down significantly from the real average (-~7%).
Unfortunately, I am still experiencing nuisance restarting of the miner when hashrate drops momentarily due to difficulty changes.
I understand that I could further drop the "average" hashrate to remedy this but I feel like that is starting to defeat the point of monitoring it in the first place.

To expand on my previous suggestion and above issue; the hashrate monitoring could be more sophisticated and less hypersensitive with the following features:
-Automatic calculation of real average hashrate
-Acceptable hashrate tolerance determined as a configurable % of real average hashrate
-Require several events of NON acceptable hashrate before initiating a restart or other corrective action

There could be a problem with that though. If the software is calculating the average hashrate automatically, it may need to ignore the first reported hashrate after each miner launch (first report is often an outlier)


Regarding over-temperature protection:
In the case of DSTM's ZM Miner: when --temp-target is defined, the miner starts reducing the workload to prevent the GPU from exceeding the set temperature.
It seems(please confirm?) that autorun currently takes the set temperature as defined for the miner and uses this as the temperature limit for its own purpose.
So, the miner never gets the opportunity to respond because autorun shuts it down at the same point where the miner should start down-regulating the workload.

Can autorun be modified to allow the max GPU temp to be set by the user rather than taken from the config parameters used for the miner?
For example: miner set to reduce workload at 76 degrees and autorun resets machine at 80 degrees. That way, autorun does not interfere with the miner.


ZM Version 0.5.7 has been released. I'm going to give it a whirl on one rig with autorun and see what happens.

Today version 1.8.2 released!
Changelog - [1.8.2]

• Significant code optimization.
• Clear the error list.
• Fix server switching. Added a message to which server number the miner switched.
• Added ignoring of additional coins during ether mining. Added support for classic ether.
• The restrictions for the config file and the file are increased.
• Most likely, the bug of the configuration file is completely fixed.
• The MSIA timeout setting has been moved to the configuration file. The waiting time is reduced by 20 seconds.
• Fixed the problem of determining 0 H/s (Sol/s).
• Added error handling of type: unknown error, cuda failed.
• Added support for XMR.
• The timeout of shares is increased to 15 minutes.

Ewbf 0.3.4 version
Dstm 0.5.6 version
Claymore 12.6 version (Equihash)
Claymore 10.2 version (CryptoNote)
Claymore 10.2 version (Dagger-Hashimoto)

Hello! Thank you very much for your reply and detailed info. I fixed some issues what you talking about in 1.8.2, please try it and report to me.
About hashrate - good idea - i will think about it, thank you! But please try to use not exact value but a little bit lower.


Hello! Thank you for reply and using my script! Yes, try to use little bit lower hashrate, not exact value but with ~2%-5% difference.
Thank you very much!

Yeh, i've set it to 1750 and working good so far.

Hi Acrefawn,

Thanks for your excellent work here.

I am finding that I am experiencing a couple of issues with this using DSTM's miner 0.5.6 with Autorun ver 1.8.1.

Issue 1:
When the server changes difficulty on several GPU's at once, there is sometimes a significant, temporary hashrate drop which autorun incorrectly identifies as a real problem and restarts the miner.

Issue 2:
I regularly receive the "Loaded too many GPUs" report on only one of my rigs.
This is a 7 card rig but for some reason Autorun is detecting 14/7 cards despite the problem not actually existing in the miner.

I suspect that this is related to an erroneous log output from the miner as follows; note that the miner has reported two iterations of each card before outputting the "average" line (the last line of the extract below)

2017-12-07 9:39:51 AM|   ========== Sol/s: 2898.4 Sol/W: 3.89  Avg: 2874.0 I/s: 1565.8 Sh: 39.13  1.00 357
2017-12-07 9:39:51 AM|#  GPU4  server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-07 9:39:53 AM|#  GPU5  server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-07 9:39:55 AM|#  GPU6  server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-07 9:39:58 AM|   GPU0  63C  Sol/s: 291.4  Sol/W: 3.94  Avg: 432.1  I/s: 158.8  Sh: 4.97   1.00 349
2017-12-07 9:39:59 AM|   GPU1  67C  Sol/s: 279.9  Sol/W: 3.80  Avg: 419.6  I/s: 149.5  Sh: 5.31   1.00 352 ++
2017-12-07 9:40:01 AM|   GPU2  54C  Sol/s: 295.4  Sol/W: 3.99  Avg: 424.5  I/s: 154.2  Sh: 3.82   1.00 344
2017-12-07 9:40:03 AM|   GPU3  66C  Sol/s: 284.6  Sol/W: 3.74  Avg: 421.5  I/s: 152.0  Sh: 6.15   1.00 375 +
2017-12-07 9:40:05 AM|   GPU4  70C  Sol/s: 298.7  Sol/W: 3.83  Avg: 435.5  I/s: 159.8  Sh: 6.31   1.00 416
2017-12-07 9:40:05 AM|>  GPU0  62C  Sol/s: 229.0  Sol/W: 2.06  Avg: 229.0  I/s: 121.5  Sh: 5.99   1.00 343 ++
2017-12-07 9:40:06 AM|>  GPU1  67C  Sol/s: 225.1  Sol/W: 2.02  Avg: 225.1  I/s: 120.1  Sh: 2.96   1.00 344 +
2017-12-07 9:40:08 AM|>  GPU2  54C  Sol/s: 219.8  Sol/W: 2.06  Avg: 219.8  I/s: 119.7  Sh: 5.99   1.00 352 ++
2017-12-07 9:40:09 AM|   GPU5  71C  Sol/s: 276.1  Sol/W: 3.73  Avg: 437.3  I/s: 148.8  Sh: 7.44   1.00 344 +
2017-12-07 9:40:10 AM|>  GPU3  66C  Sol/s: 222.7  Sol/W: 1.95  Avg: 222.7  I/s: 119.4  Sh: 5.81   1.00 351 ++
2017-12-07 9:40:11 AM|   GPU6  49C  Sol/s: 162.0  Sol/W: 3.69  Avg: 248.7  I/s: 84.8   Sh: 3.79   0.96 360 +
2017-12-07 9:40:11 AM|   ========== Sol/s: 1888.2 Sol/W: 3.82  Avg: 2819.2 I/s: 1008.0 Sh: 37.79  1.00 362

As a side note;
Inputting the real "average" hashrate into the config.bat file tends to cause autorun to detect too many instances of low hashrate because any reported hashrate below the average appears to be considered an error.
I'd suggest this parameter would be better if named "minimum acceptable hashrate" or similar
or
Add a configurable tolerance to the acceptable range of hashrates. ie, within (say) 10% of the average is -not- considered to be a hashrate error.

Further, (just an idea) rather than the user nominating the average hashrate, perhaps autorun could automatically detect the actual average hashrate from all log files and store it in the config.bat file.

Happy to discuss this with you if the issue isn't clear from my description. Sorry that my input is not in the form of code change suggestions, it's beyond my capability.
That said, using this script has been educational and I'm thankful that you have released it open source.
Thanks again.

Hello there, try  lowering the average speed to 1780-1800 on the config.bat then u will not have any problems (script sensing avg hashing speed is below the normal), you dont need to mess with the hashing errors at all.

hope this help you.

DSTM miner gets killed due to low hashrate average, even tho i've set the hashrate errors to 99

Windows 10 PRO
6X P106-100 GPU's

Core + 225 MEM + 200 POW limite 67 TEMP 68

I'm using 1830 as ~

DSTM miner always start with a higher hashrate, and starts to drop. Thats why i'm getting alot of hashrate erros.
So how to fix this, i've set 99 hashrate error, and after 20 minutes. zm.exe miner gets killed
http://prntscr.com/hjxkyp
Why doest it say "hashrate error = 0/99 and then 57/99
Should i set it to 1000 or what?