Yes, the install function is only called if the error string from the miner trying to call sv on ends with " not found":

https://github.com/psycodad-bct/bitmain-tools/blob/master/scripts/l3plus_autotune.py#L158

On top of that a flag is set, that makes sure that it only tries once to install the binary (most failures installing it exit the script anyway) per script run:

https://github.com/psycodad-bct/bitmain-tools/blob/master/scripts/l3plus_autotune.py#L199

I just saw this very same error on one of my miners a few hours ago, but I couldn't find the cause for this behaviour so far.

I had not much time to dig deeper yet, but what happened here was that /config/sv (the slightly varied binary of jstefanops work we install on first run of the script) was truncated from  the 9788 bytes it should have to something around 1000 bytes and has changed permissions (hence the Permission denied).

The simplest way to resolve this is by removing the /config/sv file on the antminer via ssh and letting the script re-install it again. Though my miner where I saw this had to rebooted afterwards as the PIC version suddenly was 0x00 (probably meaning the PIC MCU didn't reply anymore). After a cold boot things were all fine and dandy again and I successfully run the script on that miner.

Could you check for me two things with the miner where you saw that:

1. Was the miner rebooted recently and/or did you have to reboot it to fully recover from this?
2. Before you remove the (assumedly) truncated /config/sv, can you check what is in there with i.e. 'hexdump -C /config/sv' (this might give us a hint what process is responsible for the corrupt binary)

Simply open another terminal and start it against another miner (or use screen or tmux). Even on an old and outdated PC you should easily be able to tune a dozen or so miners at once.

Just make sure you do not have 2 script instances running against the same miner at the same time (it should not have any desastrous consequences but both scripts will probably fail with an error when they try to read out or set voltage at the same time).

With such low frequency your miners should already be set to minimum voltage/maximum undervolting setting of 0xfe (254). You can't undervolt more than this so no need for tuning.

Thank you very much for the reports.
It actually finishes because it thinks the miner is stable and under the max. errror-rate (which I have currently set to 0.2/min, or 1/5min per chain).
The downvolting kicks in as soon as a chain has 0.0 errors in the 10min avg. and the voltage increase kicks in when a chain has more than 0.2 errors per min in the 5min average.

When I look at your end-results, the script assumes the miner as tuned when it does not make any changes within 10min to voltages as it thinks it has found the sweet spot between no errors and too much errors.

I will revisit that part of the code and see what I can improve there, but from what I see it does actually tune your miner, but I agree it should try harder/longer:


| Start 19:20.46 | 0xa0 | 0x8b | 0xcd | 0xa9 |
| Start 19:20.46 | 59 C | 58 C | 54 C | 53 C |
| End   19:35.46 | 0xa0 | 0x92 | 0xcd | 0xb0 |
| End   19:35.46 | 59 C | 58 C | 54 C | 53 C |

| Start 13:39.55 | 0xa3 | 0x6f | 0xa3 | 0x9c |
| Start 13:39.55 | 60 C | 61 C | 58 C | 56 C |
| End   14:01.55 | 0x9f | 0x7d | 0xb1 | 0xa2 |
| End   14:01.55 | 60 C | 60 C | 57 C | 55 C |

| Start  9:40.40 | 0x87 | 0x67 | 0x87 | 0x87 |
| Start  9:40.40 | 60 C | 59 C | 57 C | 54 C |
| End    9:55.40 | 0x8e | 0x6e | 0x87 | 0x87 |
| End    9:55.40 | 59 C | 59 C | 57 C | 54 C |


I was trying to make sure the script doesn't run forever and stops/exits as soon as it can, but I probably went a bit too far wrt this.

For the moment feel free to run the script multiple times, I even recommend to re-run it everytime ambient temperatures change noteably (>=2°C difference). Simply put, the colder the less voltage needed.
Whenever you change frequency you should re-run the script or manually re-tune them anyways.

If you want to run the script multiple times in a row unattended, use a command like below:
^This will run it three times in a row, just as a workaround until I come up with a smarter solution on finding the right point in time to declare the miner tuned.

I will post, once I have an update.

Thanks for checking in. No, unfortunately 0xfe equals 254 and ist the highest undervolting you can set.
If you have 4x 0xfe set, there is nothing more you can do to save on energy (except lowering frequency further), this script doesn't help you then as it is about to find the highest undervolting setting where you miners still work reliably.

You could however get possibly more hashes/W if you increase the frequency to the point where you still can run them with 0xfe on all or most blades. And if you are willing to set a frequency where you do not get 0 errors on all chains with 0xfe, my script can help to find the highest possible setting with lowest possible errors.

I think so, please check this post:

https://bitcointalk.org/index.php?topic=3835841.msg37448663#msg37448663

First, the problem with negative sleep is fixed in the current github version, please update and see if it goes away for you.

Regarding the problem of not getting undervolted enough, could you pm me the contents of one or two report files the tool generates when finished?
I am aware the mechanism for finding the sweet spot voltage-wise is far from perfect yet, but in my tests I always got very accurate results, meaning it improved my manual tuning by a lot.

Thanks, that's something I can chew on. It lacks a , after Type":"Antminer L3+ Blissz v1.02"}. Funny how all versions of cgminer I dealt with output invalid json, though every version places the problem somewhere else.

I have pushed an attempted fix to github, though it's a bit fly-by-night as I don't have a Blissz fw to test it beforehand.

Thanks for testing the script and reporting back.

Never seen that error here. But I see that we're trying to sleep a negative number of seconds because your ssh connection take longer than 15s each, which makes the computer say "No" in a very Little Brittain like manner.
Will work around this and push an update later today and post here when it is fixed.

I guess that's the reason it never finishes and therefor never really does its job of lowering the voltage.
Have you ever seen it finishing with lines like the following or does it always drop out with an error?

Are you sure you pasted everything? That json reply is cut in half and is indeed invalid.

I am not sure if my receive buffer is too large with 32k, I have changed that to 1k and pushed the update to github again. Please make also sure you paste the complete output.

I have pushed a quick-baked script for voltage autotuning of L3+ miners to my github (see "scripts" subdirectory):
https://github.com/psycodad-bct/bitmain-tools

The bct thread for it is here:
https://bitcointalk.org/index.php?topic=3835841

Please note that you you need a Linux computer (or possibly MacOS) with python to run this script.
It will not work under windows!

Hope this is useful for some of you.

Basically you set a frequency for your L3+ and then this script tunes the miner to the best voltage settings in terms of optimal error_ratio/power-consumption per board.

Thanks for testing the script.

It seems to fall over while parsing the cgminer json output.
I am a bit at loss, would need to see the raw json output from cgminer.
EDIT:
You could try to add a print statement just before the line it falls over, i.e. before line 95 add
  print json_resp
and post or pm the output.
I have pushed an update to github which should print the json data so we can see whats wrong or where it falls over.
Please update with git pull and post or pm me the output.

Also, are you running the latest Bitmain firmware 1.0.1.3 ?

Since jstefanop was so kind to release his demo code for voltage setting on the L3+ we could finally undervolt our L3+ and save some of those precious watts.

Though the process of tuning every hash board is time consuming and boring (at least after the third L3+) and I soon wished there was a way to automate this trial and error process similar to what General Tarkin did on the Titans.

So I hotglued some python script that does the whole process automatically and does not require you to install jstefanops binary on every single miner. But you need a Linux (MacOS might work) machine that can reach the miners you want to tune over the network.

Note: Just to be very clear: The script needs to be run from a different computer than your miner!

If you are willing to try this alpha software, head over to github and checkout my bitmain-tools repo:

https://github.com/psycodad-bct/bitmain-tools

Usage in the simplest form is just:

All options are printed if you supply no arguments to the script:

The script may take anywhere from 30min to several hours or can even refuse to complete if your miner is too unstable. If that happens you can try to use the --skip option to skip tuning one or more chains/hashboards and set them to the best possible value manually.

I did this to save time on tuning and re-tuning my L3+ miners and thought I'd share it here.

Disclaimer:
This script has at best pre-alpha-quality (or even less) and comes as-is with no warranties at all. I have tested it heavily and to the best of my knowledge it should do no harm, but it has obviously when playing with voltages the potential to damage your miner and even if not it will probably void your Bitmain warranty.

Use completely at your own risk!

If in doubt, use the source Luke!

To check for coinds being alive it is most of the time sufficient to query rpc with almost any command like getbalance or getinfo.

If on a unix-like system like linux, you can run a cronjob that queries getinfo and if timed out, restarts the daemon i.e.:


I am using a way more elaborate script that reads coinds to check from a text file.

HTH

As I am brewing up my own autotuner, I needed stefanops binary to be able to just report voltages without prior setting.
My changes and a slightly improved binary (segfault fixed and a few output improvements) can be found here:

https://github.com/psycodad-bct/bitmain-tools/releases/tag/v1.01

Again thanks for jstefanop for releasing his code. Hope this is useful for some of you.

Usage is the same as the original, except you can omit the voltage or voltage and chain and just get the current settings reported back then:


Disclaimer: While I have done everything to avoid problems and tested it extensively I know barely what I am doing here.
So use completely at your own risk!

You got a point, I get timeouts, red API sign and manual tests get me sporadically access denied and timeouts from different network locations to the Cryptopia API.

Tough that isn't that hard to guess in this thread, isn't it? Are you right now having problem with the Cryptopia API or not, as simple as that.

Anybody else seeing problems with Cryptopia API?

Yeah, that's exactly why Microsoft was rushing in 94 to devote their Fax team to developing Internet Explorer for 95plus once it dawned the rocket scientists at Microsoft that the future is surprisingly the internet and not faxing...

For me, Gates can be characterized as somebody who got rich by stealing other peoples ideas and concepts (and software).

Wake me up when somebody I take serious says something interesting...