It could be hard for smal farmers to sign a contract with a solution provider. For big farmers this could be something. But the dao could also decide to arange this for every farmer. Now 50% of the utilization tokens is going to the solution provider, it may could be splitted in 40% to solution provider and 10% to the farmer. In this case every farmer provits from utilization
Incentive for farmers to attract workloads
2 Likes
Wouldn’t it make a lot of sense for larger (or small, but may not be worth all the effort) farmers to become their own solution providers? We’re planning to build a farm that is powered on 100% renewable energy from our own production and I have already been speaking with some potential customers that would be interested in booking our green capacity. If we market our capacity ourselves, I think benefiting from additional utilization rewards can be a great incentive (Thanks to @Dany for pointing this out to me).
3 Likes
I think you could have the 2 roles at the same time: solution provider and farmer. In practical terms you (as a solution provider) could establish an agreement with yourself (as a farmer). This solution should be accepted as good and I am sure it would create new possibilities for those who want to start a provider business. If in the future they need more capacity they could invest on their own farms to scale or go with an hybrid model.
3 Likes
Good idea indeed. True, most farmers will not spend the time and effort to look for a solution provider and try to get a deal with them (% wise).
But if we would do it by default, this could have a lot of impact on token distribution. Which would be good and possibly bad, but would need to be thought true very well. There would be less, by default, for a solution provider to earn for example. Or what would be a good % for the farmer to create enough incentive to attract workloads?
That is currently perfectly possible I believe. If your approval for solution provider is approved, regardless if your a farmer.
But there is a difference between a farmer and a solution provider.
- Farmer: providers capacity
- Solution provider: provides workloads on that capacity
So just being a farmer will not get you approved as a solution provider. You will need to be able to show how you are actively adding workloads to the grid, with a solution you created like a UI to deploy on the grid, a custom created flist, maybe trough education of how to use the grid, … etc
1 Like
Yes that should be perfectly possible. This way you can earn quite some extra on your farms. You would get the monthly minting payout of your nodes, and 50% of each deployment on your nodes.
Hmmmm, I like the sound of that
This conversation has some overlap with our boosters discussion, but with the additional possibility of routing some portion of the solution provider rewards to farmers. I personally like the latter idea and seem to remember discussing it before. I think it would be very cool to see some kind of “farmer’s grid capacity marketing collective” which onboards users and generates extra revenue through the solution provider fee.
While I think that this was already an important imbalance in the rewards model to address, it’s getting perhaps even more important when nodes are able to be fully powered off while idle. The cost benefit ratio is stacked even higher against having workloads on your nodes, if they would otherwise be mostly powered off instead of just idle.
Indeed, this is the originally conceived way for v3 tokenomics to solve this issue. I’d be curious to see how the vote falls in our existing farmer community, since at least many of our more vocal members seem to be hodlers. I’ll leave details of that discussion to this other thread, but just say here that I don’t think it’s the solution to pursue right now.
Boosters provide a simple way to at minimum keep things fair for farmers who pay more for power because their nodes are utilized. Of course this calculation depends heavily on how much a farmer pays for electricity, but we can try some math…
Let’s say we have a rack style server with 64 CU that draws 150w idle and 300w full loaded (based on some example figures I found for Dell R620s–let me know if this doesn’t look right). It earns 2080 TFT per month. With an electricity cost of $.1/kWh or $.3/kWh:
| kWh/month | Monthly cost ($.1) | Monthly cost ($.3) | |
|---|---|---|---|
| Idle | 108 | $10.80 | $32.4 |
| Loaded | 216 | $21.60 | $64.8 |
Meanwhile, the value of TFT farmed every month is $62.4. So our farmer paying $.1/kWh needs to be boosted ~17% to break even, while our farmer paying $.3/kWh needs a ~52% boost.
I only checked after choosing these example numbers, but the world’s average electricity price was $.13/kWh and the highest was $.412/kWh as of June 2022 (the reality is currently changing fast, however, especially in Europe).
Again, that’s comparing loaded to idle. Comparing to nodes that are using negligible electricity simply proving that they still exist by powering up on a daily basis is a bit different. At least one node needs to be powered on at all times to be able to wake up the others. This means that there’s a significant jump in power consumption whenever a new node needs to wake up and start running workloads. I won’t try to full model this case until I have more details on the implementation.
1 Like
Let’s consider another approach to this that keeps things pretty simple and doesn’t involve minting any more tokens than we already are. That is, simple directing some of the sales channel fee toward the farmer. In order to be a net positive for the farmer, the additional payment they receive would need to be more than the additional money they spend on electricity.
I did a bit of analysis in an attempt to find out how this would work in practice. It’s pretty tricky, because there are quite a few variables and not so many examples of measured power consumption for given setups. If you can provide any figures for how much power your nodes draw under different loads, or any links to resources like this, please provide them in the replies.
Comparing power cost to available sales channel revenue
Working with sales channel revenue is simple, because it’s always the same USD figure, regardless of TFT price. Therefore, we can just look at expected cost of electricity compared to what the grid user is paying for their deployment. The downside is that any discounts applied to the price also discount the available sales channel revenue as a percentage of deployment cost.
Discounts
It’s not ideal for farmers revenue to depend on whether the users of their nodes take advantage of discount opportunities. For larger farms, this may tend to average out. For single node farmers, having their node rented as dedicated, with a substantial discount, is an obvious disadvantage in the context of this proposal. Likewise for the case where a single node farmer has their node reserved at any level by someone utilizing a “staking” discount.
I’m not going to try to fully solve concerns around discounts here. Rather, I’ll just check how the situation stacks up when the largest discounts are in effect, and whether there’s still enough revenue to at least pay for farmers’ electricity. One potential solution would be to rebalance the payments to farmers according to the effective average discount across the grid for a period of time.
How much energy does a server consume?
The real answer here is that for every possible permutation of hardware configurations and workloads, there’s a different level of energy consumption. Some vendors have at some points in time published some measured power consumption figures, but they’re not common. Again, if you can point me to any resources around this or quote any figures you’ve measured yourself, please let me know.
For this analysis, I’m going to use an example from Serve The Home. In this article, they provide some figures for server power consumption under heavy CPU load. Here’s the test configuration:
- Server : Dell EMC PowerEdge R640 1U 10x 2.5″ Chassis
- CPUs : 2x Intel Xeon Platinum 8180
- RAM : 384GB in 12x 32 DDR4-2666MHz RDIMMs
- Storage Controller : PERC H740P
- SAS3 Storage : 5x Samsung PM1635a 400GB Mixed Use SAS3 12gbps SSDs
- NVMe Storage : 2x Samsung PM1725 1.6TB U.2 NVMe SSDs
- OS Storage : BOSS controller card with 2x 120GB m.2 sticks
- Networking : Mellanox ConnectX-4 Lx dual-port 25GbE
- Power Supplies: 2x Dell 1100W
These are older, but not ancient CPUs, released about four years ago, which are reasonably efficient. The test workload ran the CPUs at 100%. This is unlikely to happen in practice, but it represents the upper bound of what a reservation could drive this node to consume. Measured power consumption was 500w, which corresponds to about 360kWh/month.
Here’s the total cost per month at a few different energy pricings. I’ve also included a 50% figure for reference, not suggesting the 50% CPU load corresponds precisely to half the power usage:
| $.1/kWh | $.3/kWh | $.5/kWh | |
|---|---|---|---|
| 100% | $36 | $108 | $180 |
| 50% | $18 | $54 | $90 |
How much is the sales channel fee for this node?
If this same server were attached to the grid, the cost to rent it and associated sales channel fee looks like this (this assumed 50% staking discount is enabled by default, as it currently is). I’ve also computed half of the sales channel fee, assuming we want to leave at least half to be consumed by sales channels.
| Default discount | Dedicated node + max staking | |
|---|---|---|
| Total Cost | $751.22 | $165.89 |
| Sales channel fee | $375.61 | $82.95 |
| 1/2 sales channel | $187.80 | $41.47 |
Looking at the extremes here, this tells us that a farmer paying $.1/kWh who has this node rented as a dedicated node with maximum discount can still turn a profit getting half of the sales channel fee when the node is using its maximum power draw. That’s pretty encouraging, especially since the node would probably use much less energy in reality. If this farmer was able to claim the whole sales channel, by marketing their own capacity as a non dedicated node, they could earn an extra $300 in TFT per month!
On the other side, a farmer paying $.5/kWh can also make a small profit earning half of the sales channel discount when the node is fully rented as a non dedicated node and using max power. When the node is rented as dedicated node with maximum staking discount, even the entire sales channel fee won’t cover the farmers electricity when the node is drawing 50% of its maximum energy.
Conclusions
Overall, I think that allocating some part of the sales channel fee to farmers is a promising way to ensure that running workloads is a net positive. Even with a very simple scheme as analyzed above, this would work for a wide array of cases. By pooling the funds together to smooth out the dips caused by discounts, even farmers with expensive electricity could profit when their node is rented as dedicated with a discount.
With a pooling scheme a larger percentage, up to the entirety, of the sales channel fee could be allocated to the pool in cases where a sales channel is not involved. Successful sales channels would then divert some revenue from farmers, but assuming they are driving demand for TFT and its price increases, this should be a net positive for the ecosystem. Farmers who act as sales channels would get their sales channel cut before it hit the pool, while the rest would be pooled and distributed as normal.
The proof of utilization distribution would look instead like this:
| Percentage | Description |
|---|---|
| 35% | Burned |
| 10% | ThreeFold Foundation |
| 5% | Validator Staking Pool |
| 0-25% | Solution providers & sales channel |
| 25-50% | Farmers |
Some final thoughts:
- If the price of TFT goes up and the entry price for farmers is increased, pool distribution could be scaled down for farmers with a lower entry price, who are already earning a better profit
- Less efficient nodes may still be net negative when they are utilized, especially where electricity is expensive. This is to be expected for gear of a certain age, but efficiency must be measured in energy per unit of performance, not just energy per core or GB of disk
- Locking tokens earned in this way could also help to delay any sell pressure from this scheme, and provide a further incentive for farmers to keep their nodes up when they are running workloads
3 Likes
Interesting fact, 45&49 on Devnet both see usage up to their capacity regularly, i have not seen sustained cpu load above 30% nearly at all on either of them.
Awesome post! If implemented in this way I think it could be very beneficial to farmers and the project as a whole. Seems like you’ve already thought everything through to a great extend.
I especially like the idea with the pooling to keep rewards the same for all types of utilization (dedicated, discounted etc)
Just one question: with the statement below you mean farmers will receive their cut of the sales channel or that their sales channel tokens will be cut off? (Sorry if this should be clear)
Edit: now that I think about I’m pretty sure you mean farmers will receive their cut beforehand. Otherwise farmers marketing their own capacity would be disadvantaged, which probably makes very little sense.
1 Like
A great post. In my opinion, this is the solution to compensate farmers for the increasing energy consumption due to the use of the server. At the moment you prefer not to have utilization on your node, as this will increase the costs. As a result, it is now more profitable for farmers to make their node as unattractive as possible. While nodes should be made more attractive, for example by investing in IP addresses. In addition, I never understood that farmers do not receive any rewards for using their node, since this costs more electricity and the hardware will also wear out faster. This will also contribute to the problem of farmers shutting down their node because something has been deployed on their node.
2 Likes
Hi @liqearce. Some good points in your message. We have been at both ends of the farming token earning spectrum. V1 of the farming tokonomy included a fraction of the usage tokens going to the farmer. This had two downsides:
- being recognized as a utility token cannot include payment income for the “utility” owner. This would make the token a payment token, which is far more regulated in certain parts of the world.
- many farmers felt like they were “missing out” if their nodes were not used, and were looking at ThreeFold to promote, market and in the end create usage on their nodes. Some farmers (and farmer collectives) were actively looking into creating use cases and becoming service providers. While possible, this is a very different involvement and requires different skills.
In order to overcome this difficulty te tokenomics where changed such that the new token economics for farming only wooud match the old farming + utilsation income for farmers. This took away the feeling of missing out and made farmers, farmers.
Now with a changed world in terms of costs involved to operate a farm, an unused farm is the lowest possible cost level incurrent to be involved in Threefold farming. And with this changed world, we are (again) changing and improving things:
- unused servers can the turned off. More details are here. This needs some more advanced workload planning inside a farm to fill the used server up first and then spin up a new server when up and running capacity is maxed out.
- looking to create an affiliate program, where individuals (anyone basically) that present additional capabilities (an flist, a program to report on usage, anything) can claim a percentage of the utilization fee. the community could
Blockquote
consider including an affiliate fee for the high price for power.
This is certainly a helpful data point. Since devnet capacity is free to use, I think it’s likely undershooting what a mainnet farmer would see with their node rented by paying customers who will be less likely to leave idle VMs up or reserve more capacity then they actually need.
I’ve actually been considering moving them to test net for that reason, I feel like there may some ips being used by stale deployments since they don’t bill real tft
What happens with the 0-25% solution provider & sales channel cut when neither are used?
I mean if I simply deploy a VM on the grid myself, no sales channel is used. The solution provider in this case is the creator of the VM-Weblet (ThreeFold foundation)? If that is the case, is it even possible to deploy anything on the grid without using a solutions provider?
1 Like
Very good question @jakubprogramming
I think this documentation might clarify some notions here.
- Each solution provider and sales channel gets registered in TFChain and as such the distribution can be defined and calculated at billing time.
- For billing purposes, ThreeFold DAO will check if it is from a known sales channel or solution provider. If yes, then the billing smart contract code will know how to distribute the TFTs. If the channel of solution provider is not known, then the 50% will go to a DAO owned Community Grant Wallet.
- For Certified Farming, ThreeFold Tech can define the solution & sales channel parameters, these are channels as provided by ThreeFold Tech.
Source: TF Library
2 Likes
I’ve not checked the TF Library for some time, as it usually seemed not always to be completely up to date. Maybe this has changed? Anyway thanks for clarifying this!
1 Like
Oh the library has had a massive overhaul.
2 Likes
Check it out. I visited it for the first time in a long time and was impressed.
2 Likes