@dstm
There are a lot of questions and requests floating around in here about development. Would you consider providing something of a road-map in the first post of the thread to explain upcoming features, improvements and timeline milestones?

Perhaps some FAQ's and basic troubleshooting too? the thread is flooded with repeats. Some examples;

Q: Can you give the option to remove devfee?
A: No, I like money

Q: Why does this miner crash all the time?
A: Because you scrubs are terrible at overclocking,
    Get acrefawn's automonitor and
    Limit TDP by locking voltage in AB rather than setting max TDP (ctrl+f > select point > L > Apply)

Q: Why am I getting cudaMalloc Failed?
A: Because your pagefile isn't large enough

Q: What does "+" mean?
A: Consult the readme

Q: Waahhh my 1080 Ti doesn't get 1000sols
A: That's not a question

Hi Acrefawn,

I am finding that this script makes maintaining my mining operation much easier and more profitable. It has operated without error for me since I've started using it. Thank you.


Regarding implementation of the pool switching feature in Autorun while using DSTM miner.
Sometimes the miner loses connection to the server. The following error appears: "connection closed by server r:0".
Autorun responds by closing the miner and connecting to the alternative pool for 30 minutes before returning to the primary pool.
I have found that when autorun is not active, the miner is often able to restore its connection to the pool within 15-20 seconds.
However, the miner's auto-reconnect is often interrupted when autorun closes it to change pool.
Would it be possible for autorun to wait and monitor for say, 30 seconds, to give the miner chance to reconnect itself before executing the pool change?

This would prevent nuisance pool switching and reduce the amount of notifications received by the user on Telegram.

(I understand that there is a bigger issue here which is the miner disconnecting from the pool. I blame it on my ISP.)

Thanks again,
Starky

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.

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.

Thanks for the suggestion.
I agree, but I found that increased memory speed only starts to make a significant difference when used with higher core frequencies (say, 1850+ ish).
I was aiming for good efficiency which meant keeping core freq relatively low - usually ending up somewhere around 1670-1800MHz (at 800mV) depending on the quality of the chip.
Pascal seems to be very efficient at this voltage and capable of a significant overclock which is ofc desirable.
So, at these core frequencies, the reduced memory freq further reduced the total power consumption without significantly hindering the hash rate.

All of this said, it makes almost no difference anyway. You can vary a cards power consumption (reported) by up to about 4-5W though memory clock speed adjustments in my experience.

Interestingly, ZM uses less power than EWBF -and- gets a higher hash rate at the same time. It made my sols/w epeen shoot friggen rainbows.

I'm getting great results with this miner. Many thanks for your work, dstm.
No crashing here.

v0.5.3 was closing itself(?) occasionally, I assume it was losing connection to the pool and running out of reconnect attempts.
I'm testing 0.5.5 now to see if the problem still exists without the reconnect attempt limit.
Should really use the log I suppose.

GTX 1070
420sol/s @ 4.0 sols/w
Afterburner 800mV, +188mhz core, -50 mem

GTX 1080
515sol/s @ 4.2 sols/w
Afterburner 800mV, +125mhz core, -50 mem