Helium Miner How To Increase Witnesses By Editing sys.config inbound outbound connections

You’re here because you want to increase valid witnesses on your helium miner. You may have seen the sys.config file discussions on github or maybe you find the dreaded @miner_onion_server:send_witness:{207,5} failed to send witness, max retry failure message. Here’s how to edit your sys.config on your helium miner to increase your maximum inbound and outbound gossip connections.

First, you have to find the file ‘sys.config’ and make sure it’s the correct sys.config file! I’m doing this on a Milesight UG65 HNT miner hotspot so your mileage may vary but it’s similar on all miners.

find / -name "sys.config"

That will scan your file system and find all occurrences of the sys.config configuration file.

On the Milesight UG65 Miner, there are different sys.config files but the ones you want to edit are the ones in the …/miner/config/sys.config format. Do not edit the ones that are in the /lib/gproc-0.8.0/priv or /releases/2002.03.07.0 directories as those are the wrong ones.

To edit the file on your miner, you use “vi” as the editor. Yes, vi is a cumbersome editor but it’s all we have to work with. In my example (yours will vary but follow the structure) there are 3 files in total that you have to edit to make sure the changes are there and are not overwritten. In the above example, there’s 7 files but only 3 of them follow the /miner/config/sys.config format. #1, #2, and #5. You may only have 2 and that’s fine. Just edit the files that are ………../miner/config/sys.config and nothing else.

Before you edit files, you may want to create a backup. I have found that /etc/urlog/ directory is a great place to put things so they’re not overwritten by the system as it periodically checks for modified files and the reason why you have to edit multiple copies of this sys.config file. To make a copy of this file into the /etc/urlog directory: (syntax: copy original_file_name destination_directory)

cp /mnt/mmcblk0p1/overlay2/2e8034dae002227cafd89ce2e460d11cde7aab006dc6f1df0ffb628abb23a11b/diff/opt/miner/config/sys.config /etc/urlog/

That will make a copy of your sys.config into /etc/urlog/. If you ever need to restore it:

cp /etc/urlog/sys.config /mnt/mmcblk0p1/overlay2/2e8034dae002227cafd89ce2e460d11cde7aab006dc6f1df0ffb628abb23a11b/diff/opt/miner/config/

Ok, let’s get to editing! In my previous example, to actually edit the file you would type:

vi /mnt/mmcblk0p1/overlay2/2e8034dae002227cafd89ce2e460d11cde7aab006dc6f1df0ffb628abb23a11b/diff/opt/miner/config/sys.config

All on one line, obviously. That will bring up the editor with the file (copy & paste works best, also obviously!)

Quick vi editor tutorial: you have to hit the “i” key to go into INSERT mode. Even if you’re deleting, “i” is critical for making any changes. To know you’re in insert mode, the lower left hand corner of your ssh session will change from – to I indicating you are now in vi insert mode.

When you are done making your changes, you press the <ESC> key and your vi editor will go back from I to – in the lower left hand corner indicating you are no longer changing/editing text in the window.

To save, when you’re in the command mode (- in the lower left corner) type:

:wq

That is the command to “w”rite and “q”uit. This will save and exit your changes in your vi editor window.

Now, if you screw it up – and with vi it’s easy to do… believe me on this one… go into your command mode by using the <ESC> key (lower left goes to -) and type:

:q!

This will quit and the exclamation mark means you’re sure you want to abandon any changes you may have made. Great way to simply get out and start over if you accidentally change something.

Ok, now that you are a vi unix editor expert, here are my current sys.config file recommended changes – and bear in mind that this is a work in progress.

Scroll down and feel free to change the peerbook_update_interval (900000 is the default), max_inbound_connections (6 is the default), outbound_gossip_connections (2 is the default).

{peerbook_update_interval, 600000},
{max_inbound_connections, 60},
{outbound_gossip_connections, 20},

That’s what I have been using and it seems to get the peer book up to about 150k+ which is a good balance between too large and not enough. Too large puts too much work on the small CPU of the miner so you want to always watch your system load (via the “uptime” command) and the peer book size. over 300k I’ve started to notice issues – slowness and RPC miner not connected. Under 150k I get more max retry witnesses failures. There’s a sweet spot that we are trying to achieve and by lowering the peer book update interval from 900000 to 600000 – you’re putting more refreshing on the miner to keep the peer book more up to date – hopefully that also results in less p2p peer to peer errors and failures.

Write and exit the vi editor, saving your changes. Do that for any/all files that follow the format I described above. When you are done editing and saving all the changes to all the files, it’s time to restart your miner docker to start the miner with the new changes.

docker stop miner ; docker start miner

This will stop and start (different than restart – I think it’s better) your miner docker and your new changes will be implemented. Your peer book will change over time so make sure you keep an eye on your peer book by “docker exec miner miner peer book -c” and system load average by “uptime”.

Uptime will show you:

16:47:20 up 15:22, 0 users, load average: 1.69, 1.08, 1.00

In my example, the time is 4:47PM (I always set the miner to GMT/UTC which is a topic for another blog) my miner has been 15 hours since the last restart, and my load average over the past minute is 1.69, over the past 5 minutes 1.08, and over the past 15 minutes 1.00

On a dual thread CPU (which is what Milesight has), a load of 2.00 means there are no additional processes waiting for the CPU to become free. Anything over 2, there’s lag / delay due to having more requests for processor than available at the current moment. Not a huge cause for concern if it’s only for a little while, but you don’t want a sustained load average that’s close to 2. That’s cause for concern.

16:49:54 up 15:24, 0 users, load average: 0.41, 0.95, 0.98

In just over 2 minutes, notice how my 1 minute load average went from 1.69 to .41, but the 15 minute average barely changed. While the first value is important, it’s far more important when you see a high 5 or 15 minute average. That’s when you know something bad is happening.

There you go. Happy editing and good luck!

This guide for the Milesight UG65 Helium Miner is brought to you by Dennis Crawford. To help pay for server hosting costs, if you are looking for outdoor helium deployment equipment, please consider using the Amazon Storefront which has various products to use in an outside HNT environment. Or, if you’d like here is the HNT donation wallet:

13kPLKyXAVwHwTTKy7GDS5pAgM3X2A8BoeEezhSs7ZTb6cLnfwN – never expected, but always appreciated!!