We are happy to help. First off, it is important to know all the support resources you have at your disposal when setting up and running Golem.
We have help docs and walkthroughs here: Understanding Beta
We have more detailed technical information on our Github: Golem Wiki
After you bookmark these resources, feel free to check out the installation tutorial videos for your OS:
If you don't have a public IP, your router doesn't support UPnP, you need to forward ports 40102, 40103 and 3282 to your machine from your router for Golem to accept tasks. Refer to bitcoin.org. For port forwarding instructions but use above ports instead. You may also need to open the ports through your firewall. For router specific instructions on how to forward your ports go to portforward.com To check if your ports are forwarded correctly you can use canyouseeme.org
Once you have successfully installed golem you can set the amount of computing power you want to share, and wait for tasks to come in.
If you have any problems while setting up Golem feel free to reach out to us on chat.golem.network
Right now Golem supports Nvidia cards with CUDA. You can check the current list of GPU-s over here developer.nvidia.com. Unfortunately, there is no support of AMD graphics cards, but we are going to work on OpenCL in the future.
For now, there is no option to set the number of shared resources with GPU so it is possible that it will take up to 100% of your graphics card during computation. Of course, resources are shared between Golem and other tasks, so if you want to make the most out of Golem keep the card processes free of tasks. We hope that Nvidia will enable the option of setting the amount of resources in their drivers in the future.
We will implement the option to run multiple Nvidia cards on Linux in the near future, so check our blog regularly.
For the time being, we are only able to support Nvidia within a Linux environment, but this is only the GPU support MVP. After extensive testing to make sure that this environment is free of bugs, we are going to focus our research power on Windows and Mac solutions. It is not our focus at the moment, as there is no GPU docker support for both of those systems and it requires additional research.
Remember that every scene is prepared for a different use case. This issue may be caused by your scene tile size settings. Optimal resolution for GPU is 512x512.
The maximum amount of individual textures is limited to 88 byte-image textures (PNG, JPEG, ..) and 5 float-image textures (OpenEXR, 16 bit TIFF, ..) on GTX 4xx/5xx cards. Newer cards do not have this limitation.
Usually, GPU rendering is much faster than CPU rendering, but there are use cases where GPU lacks in memory. Note that, for example, 8k, 4k, 2k and 1k image textures take up respectively 256MB, 64MB, 16MB and 4MB of memory. If you have noticed any issues with GPU rendering please let us know on our #blendersupport chat channel or send an email to email@example.com including your scene specifications and task settings.
As previously mentioned at the moment you are not able to set the amount of shared GPU power so it will take 100% of your card when computing. If you have additional (for eg. integrated) cards available in your system you can set it to cover the needs of other tasks.
The peers list you see reflects the nodes connected in the bottom left corner of the app. You continually ping these peers and they ping you back to ensure your node is ready to receive work. You are not limited to these 10 nodes for recieving tasks. Whenever a task is submitted by any requestor on the network, you have a chance of receiving it. You can increase this number in CLI or config file. Increasing this number will not increase your chance of recieving a task. You can change the
opt_peer_num in the config file or using CLI.
Transactions can be awaiting for up to 30 days per our Terms and Conditions, but it rarely takes that long.
Transactions that are awaiting could be due to the other node not verifying the task yet, it could be offline at the moment for example. It also has to do with the timing of batch transactions. GNT is sent to multiple nodes in batches to save users on Gas price. Some batches leave sooner than others. An imperfect but useful analogy would be like a train that waits for a certain number of passengers before it leaves. Network speed and the amount of transactions can change the time GNT is "awaiting". A payment could be rejected if the node went offline at a critical time during verification. In this case, that transaction is likely lost.
This is something that our Concent service will address in the future, right now it is a risk of using the Beta. In this case, the transaction could still be waiting for the node to verify the work completed, IE, download the task.
Golem does not offer password recovery, because Golem does not store any of your information. When the app is installed, options to print out your password are given and instructions to write down your password and store it safely are recommended. If you lose your password and cannot access your Golem app, then you need to reinstall Golem and create a new password and node ID. You will not be able to regain access to your old node. That is why it is imperative that you write down your password when you install Golem for the first time. We also recommend Backing Up Your Golem App and Backing up Your Golem Wallet.
Golem is still in BETA and the network still needs time to grow. Requestor traffic is currently lower than Provider traffic. This could you mean that you have to wait several hours for tasks to come in. As the network grows and our business development strategies bring more Requestors to the network, you will see tasks coming in more often. If you can see your ports are open on canyouseeme.org while running the app and you have no docker errors, then all you need to do is turn on Golem and wait for tasks to come in!
Golem uses Docker containers to isolate computations from the host machine. This error means that something went wrong while creating the Docker VM at startup. Refer to our troubleshooting tips for your OS to fix this issue:
You do not need any GNT or ETH to get started as a Provider. As you accumulate GNT you will eventually want to make a withdrawal, so will need a small amount of ETH to pay for gas at that time.
We recommend providers not to change their default settings. Over time as Requestor traffic grows there will be more benchmarks for pricing. As long as the provider price is below the Requestor Maximum, and below the amount set for their specific task, your node has an equal chance of being chosen for the task.
The default settings are:
Provider minimum: 0.1 GNT/hr Requestor maximum: 1 GNT/hr
"No more subtasks" means you are requesting a
start compute but the provider already gave out all the subtasks.
"too many peers" means you want to be on the peer list of another node, and it is rejected because it is full according to the
opt_peer_num setting for that node. This does not affect your availability for work from that node. It just means that you tried to check connection and it was already pinging the max number of nodes to test connectivity.
The GNT you are seeing is in our wrapper, GNTB. To facilitate batch transfers and more secure transactions going forward, we use GNTB for transfers then it is converted to GNT automatically for your use. If you want to view your GNTB balance, you can check out the smart contract and search for your address in the "Balance of" query section.
Etherscan doesn't automatically detect GNTB transfer because batchTransfer doesn't emit ERC20 compliant Transfer event. So Golem can show non zero balance and etherscan will show no activity on the account. One can go to the GNTB contract and in the "read smart contract" tab put their address to query for the balance - it will be non zero. And after that etherscan may pick up and start showing token balance in the account view.
Your tokens will be converted to GNT eventually and you will be able to withdraw it from your app.
Golem allocates at most 75% of your RAM usage to make sure that the rest of your computer is working correctly while heavy computation are taking place in the background. So that's perfectly normal.
As a Provider, you just need to ensure you are sharing enough computing power on the network. Since that is a limited resource and the complexity of the tasks vary, there will still be timeouts. You can also make sure your connection is good to the best of your ability so you do not lose contact with nodes will computing for them.
As a Requestor, it is important to set proper task timeout settings.
Task and Subtask timeouts are the most important settings when submitting a task. So be sure to carefully consider the size and complexity of your blender file when setting timeouts.
Task Timeout: Determines how long you are willing to wait for your task to be computed. This setting should be much higher than your subtask timeout and significantly higher than you expect your render to take. If you render takes 4 hours on your personal machine, then set your Task timeout to 8-10hrs. It is likely that your render will take less time, but you need to be safe since you are paying for the render and you do not want to accidently timeout before the render is completed if your personal connection is slow or if network traffic is low. Subtask Amount: Tells the system how many subtasks to break a task into. Generally if you are rendering a number of frames you should set subtasks to the same number. Subtask Timeout: Determines the timeout threshold of every individual subtask. This setting should be significantly lower than your overall task timeout. You can use the following formula to determine a starting point for your subtask timeouts:
Overall Task Timeout / Subtask Amount + 1 hr 10hr Overall Task Timeout / 5 subtasks + 1 hr = 3hr subtask timeout
Golem Supports IPv6, although their may be issues with connecting to IPv4 nodes. even though you want to run ipv6 node you don't have to deal with port forwarding on the router (as ipv6 is always global = no NAT), the user must make sure he has ipv6 address in the routable address space (non-private), and have to make sure his routers/firewalls do not block ipv6 traffic.