Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPU support on TFChain #724

Closed
renauter opened this issue Jun 5, 2023 · 5 comments
Closed

GPU support on TFChain #724

renauter opened this issue Jun 5, 2023 · 5 comments
Assignees
Labels
priority_major type_feature New feature or request
Milestone

Comments

@renauter
Copy link
Collaborator

renauter commented Jun 5, 2023

GPU support on chain

Following the idea introduced here we now want to give incentive to GPU farming by taking into account GPU resources in the billing schema.

Pricing policy

Default pricing policies

Default pricing policies are stored on chain in the PricingPolicies storage map.
Actually we have a unique default pricing policy which is set at genesis time.
A sudo authority can modify an existing policy or create a new one by calling respectivelly create_pricing_policy() and update_pricing_policy() extrinsics.

For GPU support extending the PricingPolicy by adding an extra field would be necessary (#721).
We could call it GU for Graphic Unit.

pub struct PricingPolicy<AccountId> {
...
    pub gu: Policy,
...
}

Node pricing policy

For this new GPU support we want to allow the farmer (and maybe some other sudo authority) to set a pricing for a GPU resource.
This pricing would be specific to a given node (not a farm) and should respect some price limits in order to keep it realistic.
In case it is not explicitly set, a value from the main default pricing policies should be picked.
See discussion here #722.

So to implement this we would need to add some new features in TFGrid pallet:

  • a struct NodePricingPolicy to store the GU policy
Struct NodePricingPolicy {
    pub gu: Policy,
}

(this struct could be extended in the future for other 'by node' policies)

  • a storage map (OptionQuery) that links a node id to a NodePricingPolicy object (extended Node features  #720)
  • a set_node_pricing_policy() extrinsic that can be called by the node's owner (farmer) or sudo authority
  • a storage for min and max policy prices that can be set
  • (a set_node_pricing_policy_limits() extrinsic that can be called by a sudo authority)

Calculation from GPU resource to Graphic Unit

GRU: GPU resource in GB (?)
GU: Graphic Unit

TBD

See calculation details for other units:
https://library.threefold.me/info/threefold#/tfgrid/farming/threefold__resource_units_calc_cloudunits

Billing

Rent contract

The GPU resource can not be shared so it is only available in a rent contract context (when the full node resources is rent by a single user, aka dedicated node case). In this case, similarly to CRU/MRU/SRU resources, the entire GRU capacity should be billed.
Also each underlying node contract created on top of it will be, by definition, free of charge for the user.

Rewards distribution

Nevertheless, a different rewards distribution schema (TBD) would be used since we want to allow the farmer to receive part of the billed amount, which is not the case in current schema.

@renauter renauter self-assigned this Jun 5, 2023
@renauter renauter added this to the 2.5.0 milestone Jun 5, 2023
@renauter renauter added priority_major type_feature New feature or request labels Jun 5, 2023
@despiegk
Copy link
Contributor

despiegk commented Jun 6, 2023

I believe we can simplify this a lot, we don't need a new construct to dimension a GPU
we just need a price attached to a node (as a single fee) it doesn't even have to represent a GPU, its just a fee expressed in eg. USD per hour
if this price is set, the node can only be used dedicated, that fee will then be sent to the farmer

lets keep all very simple please

@despiegk
Copy link
Contributor

despiegk commented Jun 6, 2023

another requirement is how fast can we implement it, the more simple the better

@DylanVerstraete
Copy link
Contributor

DylanVerstraete commented Jun 6, 2023

@despiegk proposed changes won't take that long to execute and they are a safer implementention than what you propose. The problems with setting a full price for a node are:

  • Threefold get's 0 revenue.
  • Solution provider deploying on a node that has a custom price receives nothing.
  • A farmer can set high prices for all his nodes to keep the amout of load low so the operational cost of running the node stays low.
  • Farmers can now control the market by setting low prices so other farmers will miss out if they don't follow.

For me it makes more sense to allow a custom pricing and distribution for GPU's only. So when someone rents a node, the payments for using the "normal" resources (su/cu) still go through the normal distribution scheme. The payments for using the GPU are sent to the farmer.

@DylanVerstraete
Copy link
Contributor

Just had a call with Kristof, we will just allow a farmer to set a custom "additional" price. If this price is set:

  • a user can only rent this node as dedicated
  • the farmer receives the full amount if the node is used

We need to make sure the existing flows do not break when introducing these changes.

@DylanVerstraete
Copy link
Contributor

Inherently tfchain does not need to support specific features, the approach in issue #725 will make sure any feature is allowed and a farmer can price it. Closing this to declutter the issues in this repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority_major type_feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants