Farmerbot: Basic Guide for All Networks [OUTDATED]

Hey Mik, im not sure but isn’t it necessary to wipe the disks before switch to qa net? i didn’t test it cause i wiped it on the go. Just asking because of the tutorial here. if it is necessary we should add this hint.

And side hint, wiping is easy. NMT :stuck_out_tongue_winking_eye:

1 Like

Indeed it is necessary. Thanks for the reminder.

It’s planned in the: got-to-do-this-this-week list.

It’s updated. Will pull request for the manual.grid.tf version. Thanks again.

1 Like

After testing again today on QA net, everything is working fine. I can’t confirm the source of the original problem, since I didn’t maintain the nodes and config on QA net after migrating to devnet for further testing. Surely could have been a typo in my config file.

Anyway, we made the ts_client more robust in the process, so I call it a win overall :slight_smile:

1 Like

Alright good to hear. I’m pretty confident it was a mistake in twinid. The farmerbot would then try to contact the node which would fail. As a result of that it would think that the node is sleeping and would wake it up. We do that using another service that can contact the chain. That service would try to do that and fail. This failure would be send back to the caller 2 times which is not allowed. It was a small bug that is fixed in the meantime. Thank you very much for testing :muscle:. It allowed us to find that bug.

Hi all. I have released a new version of the farmerbot v0.1.0-rc13. It contains a new improvement that reduces CPU usage when the farmerbot is “idle”. You can start using it by downloading the docker-compose file (again, if you already downloaded it before) and by running the docker compose command. Here are the commands you should execute (skip the 2nd and 3rd command if the farmerbot is not running yet):

wget https://raw.githubusercontent.com/threefoldtech/farmerbot/development/docker-compose.yaml
docker compose rm -f -s
mv config/farmerbot.log config/farmerbot.log.archiverc12
docker compose up -d
3 Likes

I’m excited that the farmerbot is available on testnet already, Mik maybe it’s possible that your documentation will be adapted to the testnet and the CPU improvment command is integrated at the right place. Will give it a try tommorow…

1 Like

For testnet, just adjust the .env file as follows:

MNEMONIC="<THE_MNEMONIC_OF_YOUR_FARM>"
NETWORK=test
RELAY=wss://relay.test.grid.tf:443
SUBSTRATE=wss://tfchain.test.grid.tf:443

I’ll go ahead and drop this link to the video guide I published today too :slight_smile:

2 Likes

Thanks to @scott and Jelle via chat!!

A few Infos which would be nice in your post @mik

  1. The Farmerbot works only if you have some small amount of TFT in your chosen network.
  2. Nodes power themselves down by checking TF Chain for a new power target. They power back up by receiving the magic packet from another node in the same LAN.
  3. since you need at least one node to power up a second node. you cant test with just one node. it wont power up and wont power off.
  4. in the config-path where you run the docker-compose you have more logging for error checking
1 Like

OK very nice.

Point 1 is already added from today’s talk.

I’ll do 2.3.4. Can you say more on point 4?

I have Docker installed on a machine on the same network running Windows. I will install the farmerbot on this machine. Is it possible for the farmerbot to wake/sleep all nodes in the network? My idea is that all nodes can be put to sleep. There is no need for a permanently active node as long as the farmerbot works permanently on the same LAN.

@igg

From what I gather, you can clearly do this:

  • Run all nodes on the same LAN
  • Have one 3node active, hosting the farmerbot workload
    • You designated this 3node to be the node that wakes the other nodes

From the other posts and @brandonpille and @dylanv’s wise words:

  • The Farmerbot doesn’t have to run physically in the farm since it instructs nodes over RMB to shut down / power on nodes.
  • You can run only one Farmerbot for now
  • Currently you can only deploy one Farmerbot for each farm, so the Farmerbot can only run on one node.
  • The Farmerbot should be running all the time or not at all (this is up to the farmer)
  • Though you can run the Farmerbot anywhere you want, it doesn’t have to be on a 3node in your farm
  • If you want, you can set your Farmerbot on your farm, in the same LAN as all other nodes, and designate this 3node to be the node that wakes up the other nodes.
  • You can set different farms in different LANs and set one Farmerbot per farm.
  • The farmer bot uses the nodes in the farm to send WOL packets to the node that needs to wakeup.
    • For this reason, you need at least one node per farm to be powered on at all time.
  • The Farmerbot can run on any computer/server, it could even run on a laptop so to speak, as long as it has an internet connection, the Farmerbot will be working fine.
  • If all nodes in a subnet are powered off, there is no way other nodes in other subnets will be able to power them on again so that is an issue.
  • It should be possible to set (at least) 2 instances of the Farmerbot and have a fail over setup. Stay tuned for more information on this.
1 Like

No, you can not. You always must have one node running (set this in the config file which one). That node will send the WOL message.

The farmerbot itself doesn’t send the WOL package, it’s done via the chain and executed via the active node… if I understood everything properly. But 100%, you need at least one node running.

Hello sure, thanks for adding.

Under the directory where you set up your farmerbot, you have the directory “config” in there it creates a *.log file if you start the bot via Docker-Compose. There you can search for errors if something wont work as expected!

image

For example:
2023-03-25 13:59:28 [INFO ] [DATAMANAGER] Node 13 is waking up.
2023-03-25 13:59:28 [INFO ] Elapsed time for update: 0.08395063333333333
2023-03-25 14:04:28 [ERROR] [DATAMANAGER] Node 13 wakeup was unsuccessful. Putting its state back to off.

1 Like

Thanks I will add your points in the farmerbot guide or FAQ this week!

Hi,

Some updated info from the chat:

Update on farmerbot testing:

  1. Replicated behaviour that when one node doesn’t boot up (again stuck at downloading the image), the shutdown protocol never starts (so if one node if failing to boot, all nodes stay on). If this is by design, it would be great if that could be optional in the configuration file.
    UPDATE: this actually makes perfect sense. The farmerbot needs to have all nodes running in parallel, to uniquely identify each node. Say we have 6 nodes, one is always on and one is giving issues at boot (always hanging at downloading the zos image). During the periodic wake up, if they would shutdown the 4 nodes that booted correctly and accept that the 5th node wouldn’t boot, it would be easy to just swap the ssd containing the image of the failed node, boot the node, let farmerbot shut it down again and voila…2 nodes, one machine.

  2. Once that node is booted, the others are shutdown quite quickly. The “problem” node stays on a bit longer. How long do nodes stay on before they are shutdown again?

  3. Time in the configuration file to boot is not adhered to. I have set it to 11:30AM. I’m in the Netherlands and the system time of the machine that runs farmerbot is utc. Therefore I would expect the farmerbot to run at 09:30AM. Instead, it runs at 00:30AM.

  4. Separate issue I think, but it’s always the same node causing issues when downloading zos. The only difference with the other machines, is that it’s on a different switch. 4 nodes are on switch A, and switch A is plugged into switch B. The problem node and the always on node are directly in switch B.

OK I did some testing with the one node that did not want to boot up (stuck at downloading image). The HP Z840 has two NICs: a i218LM and a i210. When I use the i210, it doesn’t play nicely with the Linksys Switch it’s attached to. It takes at least 3-4 reboots until it downloads the ZOS image completely. I noticed that also at the beginning, when it detects the NIC, it does many times ‘connection timeout’. That’s where the issue lies I guess. I tried with every HP Z840 and they all had the same behavior.

I now moved all cables to the i218LM, and now it works flawlessly. It boots every time, also much faster (it starts detecting if anything is connected to the i218LM, plus the i218LM detects much faster).

I have set the time in the config.md file now to 07:30AM which SHOULD be 20:30 my time (unless the time in the config file is not considered at all, and just always boots at 00:30 my time).

1 Like

Good to know @checkkill

Please keep us updated on your testing. Very interesting.

I put your new information into the Farmerbot FAQ of the FAQ.
I also put the Farmerbot FAQ in the Guide.

This will be soon updated to the manual. (pull request in progress)
Meanwhile, I simply pasted the whole thing in here (on this forum post).

It’s so cool to see how we can create documentation with the help of everyone!
This guide wasn’t there days ago. And now it’s pretty dense!

Thanks @flowmotion @checkkill @igg @scott @tabularaza @brandonpille @linkmark
and everyone else for contributing to the Farmerbot knowledge base.

1 Like

For “THE_MNEMONIC_OF_YOUR_FARM” are they the same words from my ThreeFold Connect application or others?