Boosters (especially for DC farmers)

#21

You are right…I mixed up solar and wind in my head. Solar is around 30% I believe. Didn’t know that wind was at 95% though, that’s pretty impressive.

The reason for renewable actually increasing CO2 is actually coming from the EU system behind it with the carbon rights, not the tech itself. Too much detail (and I’m not an expert in it so can’t explain).

Saying that solar panels can be recycled environmentally friendly is simply not true. In the future, maybe there will be panels that can be recycled. I know of Dutch research groups working on that. But at the moment, there are great concerns for the huge amount of waste coming of the roofs in 20-odd years.

Solar and wind can never, ever be the backbone of a countries grid. Nuclear can. South Korea saw the light and went ahead with nuclear.

But I agree, no point in trying to convince each other. You have a vested, financial interest in this and are pleading the rules to your situation. I get it. As a decentralised project I think we should be careful with that.

#22

My goal in proposing boosters is not to pump out more TFT in response to market conditions. There’s a simpler way to do that, which is just to pay everyone more, and I think most everyone agrees that’s a bad idea.

The goal instead is to align incentives for farmers who provide higher levels of service by keeping their nodes online consistently, using up to date CPUs, offering public IPs, and provisioning fast and stable network connections. Really, it doesn’t matter if these nodes are in a traditional DC or not. If you can create these conditions at home or elsewhere, just as well.

Certainly there needs to be a flip side, where nodes earn less or don’t earn at all if they don’t meet certain requirements, especially bandwidth. But slashing rewards can’t be the only way to optimize the incentive scheme, especially given market conditions. The need for boosters should also decrease as utilization increases. Public IPs do pay, when people are using them. Nodes with better uptime and bandwidth will also attract more workloads, so a utilization booster can maybe handle all of these considerations one day.

Obviously more discussion is needed around this. I have some thoughts, but prefer we keep this thread focused on boosters, rather than potential new certification categories. The idea with boosters is that they only rely on data inherent to the system and can be executed automatically.

1 Like
#24

I think a network bandwidth and latency booster is doable, using something open source like iperf3 the node could run a throughput and latency at boot and each dhcp renew, average all results over a one month period.

1 Like
#25

True, also it’s maybe better to count per node /mbps. Just having a global variable like 100mbps says nothing when you have something like 10 +nodes. For 1/2 it would be ok. I would say something like 30-35mbps per node.

Imagine all 10 nodes being used and having a 100mbps connection and evert single one downloading and uploading files. You’re Youtube or Netflix is gonna load as slow as the line to Queen Elizabeth.

We have to keep in mind for people at home that have a living and children etc or just a partner and you game a lot that’s gonna use a lot as well. For the sake of the grid and deployment on those 3nodes overall performance will drop quadruply. Considering the whole connection goes over ethernet off course. Would maybe be an idea to work with something like a helium network or something (a whole different project) but it’s maybe usable, considering most places have a couple antennas.

#26

I have a helium miner in the farm, it would be an interesting concept to integrate their new 5 gigabit radio miners to provide the intra node wireless networks, But even as a current helium farmer I’d be hesitant about a partnership with helium, they don’t have the best standing when it comes to unexpected changes to farming.

#27

Hello, how is the status on the boosters?

I think for the public Ips it’s a ping thing that can be done thru a short script. To test if they are working.

I have a question about this troughpout. I have the option to upgrade to a multigig farm with 10g switching. But this should be worht it since it’s not an cheap upgrade regarding hardware. But for down/uploading to a fiber connection it will be ridicoulous fast.

But as of @weynandkuijpers qouted it’s >100mbps, can we get an % range between boosters for this?

Example:
500 mbps 5%
1000 mbps 10%
5000 mbps 50%
10000 mbps 100%

I see 100mbps quite low since most 100mbps connection can upgrade for some penny’s to a 1g connection.

I would personly start it from 500mbps. Since also most switches can provide 1000mbps, i got one here for $50 48 ports. You can get a 12 port or so for €20.

Besides, are we calculating on real network speed or ISP connection speed? Because as we know most 1g connection are never 1g but 900 or so. Also for 10g i hope to get a 9g connection in/out.

And download/upload because the highest thru coax is 50mbps upload but can go to 1000mbps download.

I think in comparing and get the most out of every farm there is a lot to do. It would be shortcoming if we are going to reward a 100mbps connection while that farm can also upgrade to a 1000mbps. I would like to see the standards a bit higher also regarding 100mbps is long not standard anymore. Lot’s of people got acces to way faster and on the server side you should never be shortcoming regarding internet speeds.

I would suggest a formulla that’s tested thru a speedtest like:

( down / 5.0 + up / 2.5 ) / nodes

Download = 1000
Upload = 1000
Nodes = 10

1000 / 5.0 = 200
1000 / 2.5 = 400
400 / 10 = 40%

== 40% extra

With a maximum of 25%

== 25% extra

Besides also once qouted before that Gold farming internet speed should be equal to amount of nodes in the farm. I think we can take that in consideration here also. A 100mbps connection with 30 nodes just won’t work when their utalized. You probably won’t be able to watch a YouTube video anymore since you internet is to ocupied.

#28

I’ve discussed a bit with @weynandkuijpers. I’ll summarize below:

  1. Any boosters resulting from uptime, bandwidth, or providing public IPs should be for DIY (and maybe regular certified) farmers who are attaining part or all of the standard for Gold Certified farmers. These boosters would not meet or exceed the extra farming rewards earned by Gold Certified farmers. Utilization boosters may also be available to Gold Certified farmers
  2. Boosters should be based on data available from TF Chain only. This keeps things simple and fair
  3. The only data we currently have as basis for boosters is the uptime reports that are already used for minting, and utilization consumption reports. The uptime data can provide some very limited idea about network stability (did the node actually report every two hours or not, despite being powered on?)
  4. Capacity verification for CPU speed, bandwidth, and validity of public IPs is in progress. When we have this data on chain, we can consider basing boosters on it

Yes, definitely. We discussed this at length in the Storage / Bandwidth Ratio thread. We still need to define bare minimums at every level before we can determine the threshold beyond which a booster makes sense. These figures need to account for utilization levels in some way. There’s no sense in farmers buying a bunch of bandwidth that will sit idle just to mint more TFT.

Real speed, definitely. The idea here again is to work with data gathered in the field.

Yep, this complicates matters considerably. Available bandwidth while everyone is sleeping versus available bandwidth at peak consumption hours when everyone is streaming at the same time will be drastically different. Bandwidth testing should happen on something like an hourly basis and scoring maybe takes the average of worst daily values or something. Traffic from any running workloads also affects what’s available to the testing program. I think only traffic over public IPs is actually logged on chain, but there should still be someway to factor this in to the calculation.

Here’s an example table for the kinds of boosters we can implement already and how they might look, from Weynand (numbers to be discussed and adjusted):

Booster Achievement Percentage 3 months 6 months Longer
1 OS uptime 99.8% up/month +5% 10% 10%
2 Network uptime 99.8% up/month +5% 10% 10%
3 Utilization 10% utilized/month + 5% +10% + 10%
If this uptime streak is broken you drop back 1 level of booster back to 0% plus.

I think maybe to best to collapse the uptime and network uptime into a single booster.

#29

I’d love some boosters for public ips and bandwidth the additional networking is about 240$ a month, nearly a grand in cat6a cabling and switches/sfps/dacs. And that’s with me doing all the labor, and setup for free.

I think you will find it extraordinarily difficult to properly benchmark a multi gig connection though. Though I think it would be possible with the tfgrid monitor update. The cub cluster could generate simultaneous connections from all over to truly benchmark thouroughout, I know in the case of my network, I haven’t got any of nodes fully setup to do 5/5, some are 1/1, a compatabily issue is causing some others to be 2.5 down and 4 up. One for some reason is 3.5/3.5… but they can all pull together a full 5/5. It’s frustrating I’m hoping to upgrade to modern switch hardware eventually so I can have the full 5/5 to the nodes.

An interesting thought, my nodes can actually push to eachother at 10g, I’ve ran an iperf benchmark Between two deployed addresses and the full pipe is there. I have the heat in place to expand this to a few 40g nodes, would be interesting for a kub cluster deployment with 4 nodes on 40g interfaces.

#30

Thank you for your reaction, and indeed very clear about the purpose of the boosters. I agree on the idle high internet speeds but off course the wat we adressing this. In the case of waiting till something is actually needed public ip’s currently also don’t do much. I do understand the whole case i think.

I think TF is also not about putting 3nodes in boxes but it’s indeed very important to have high internet speeds and public ip’s etc. Like Flux is putting every node in 1 of 3 groups regarding on the hardware. I think that’s not the option. But more to give grid users an optional quiz (a,b,c) and let the AI decide an node for every case. And then also farmers will eventully see a difference in their nodes against others. I would like to see a bit more % for use. But maybe this is not the current focus.

I like the boosters with the system behind it!

#31

I btw also saw a support for GPU’s A long time a go. I saw this was planner for Q2 this year, since ETH is 2.0 what’s the current plan on GPU’s and (boosters)

#32

It might could be an idea to use a certain percentage of the proof of utilization. Right now 50% is going to sales channels, why don’t make that 40% and give 10% of the proof of utilization to the farms. In this way farmer are rewarded for utilization, which is not the case at the moment. In this way youre stimulating farmers to create the ideaal environment for utilazation, since they get rewarded for it. At this moment there is no incentive to invest in better networking etc. We could use boosters, but then even more TFT would come in the market. Well as 10% of the utilization wil be directed to farmers, there wouldn’t come more TFT to the market.

#33

Hi, here;'s the announcement for the 3.8.0 plan. In the ZOSv3.3 section, you see the research work for GPU’s has commenced :slight_smile:

#34

I think it’s about finding the right balance here and creating the conditions for growth. Scaling as needed can work, but a bare minimum is needed to be considered for certain workloads at all. When it comes to public IPv4s, I think putting the incentives in early makes sense. The cost will only go up, and farmers may be able to secure five year leases at favorable rates.

Traditional cloud offerings typically have a few classes of underlying hardware to choose from, with fast CPUs, high performance SSDs, and that sort of thing. The Grid’s offering isn’t so uniform, so I like the idea of having some preference options during deployment that help with node selection. This will depend on having benchmark data available, both for hardware and network. That should be coming soon.

This was originally precluded in the v3 model in an attempt to get TFT to conform to a certain definition of a utility token. That may not be important anymore so we should revisit this idea. Regardless, I think there’s a way to do it, even if in an indirect way. For example, part of the sales channel tokens could be burned and newly minted tokens distributed to farmers instead.

When it comes to concerns about increasing supply through boosters, utilization is the least concerning though, because tokens are already burned in the process. The other boosters are indirectly working toward the same end, by rewarding farmers who invest in infrastructure that increases the utility of the Grid. We’ll certainly need to be careful about increasing supply in a way that can drive the token price down, because paying farmers with more tokens that have less value defeats the purpose.

1 Like
#35

How do you mean this may not be important anymore?

But why do farmers get nothing from the proof of utilization, while there server is being used and using their electricity?

I aprove utilazation is good since 35% will be burned. But 50% will go through sales channels, why not make this 40% and give 10% to the farmers. In this way farmers are rewarded for the use of their server and could compensate the increase of electricity. In my opinion this would be the most easy way. Instead of what youre suggesting: burning part of sale channel tokens and distribute newly minted tokens to farmers.

Yes thats true, to attract people to invest in better infrastructure, we could chose to give booster rewards for usage of better infrastructure or rewards for the pure delivery of these infrastructure. I think to attract those investments, it would be better to give rewards upfront. Only for the supply to increase not that fast, it would be better to reward when these infrastructure is used.

1 Like
#36

Sorry if this wasn’t clear. I was referring to the fact that paying farmers directly when capacity is used could disqualify TFT from a recognized utility token status we were pursuing in certain jurisdictions. It’s my understanding now that we weren’t able to move ahead with the classification for other reasons, thus it not being important to restrict the tokenomics in this way anymore. Using a mint/burn scheme instead could keep this possibility open.

I agree that paying farmers at least for their extra electricity expenses when their nodes run workloads is the right move. Allowing farmers to also earn a share of the sales channel when they market their own capacity can also help to grow utilization at the same time.

As utilization grows, the need for boosters based solely on providing capacity can be reconsidered. Farmers providing the right kind of capacity where it’s needed will naturally attract utilization, and utilization based boosters can balance incentives with demand.

#37