Merge remote-tracking branch 'origin/master' into feat/lpdeal-cache

This commit is contained in:
Łukasz Magiera
2024-03-17 17:31:26 +01:00
134 changed files with 6328 additions and 1977 deletions
+5 -5
View File
@@ -329,12 +329,12 @@ const (
ResourceFilteringDisabled = ResourceFilteringStrategy("disabled")
)
func DefaultLotusProvider() *LotusProviderConfig {
return &LotusProviderConfig{
Subsystems: ProviderSubsystemsConfig{
func DefaultCurioConfig() *CurioConfig {
return &CurioConfig{
Subsystems: CurioSubsystemsConfig{
GuiAddress: ":4701",
},
Fees: LotusProviderFees{
Fees: CurioFees{
DefaultMaxFee: DefaultDefaultMaxFee,
MaxPreCommitGasFee: types.MustParseFIL("0.025"),
MaxCommitGasFee: types.MustParseFIL("0.05"),
@@ -352,7 +352,7 @@ func DefaultLotusProvider() *LotusProviderConfig {
MaxWindowPoStGasFee: types.MustParseFIL("5"),
MaxPublishDealsFee: types.MustParseFIL("0.05"),
},
Addresses: []LotusProviderAddresses{{
Addresses: []CurioAddresses{{
PreCommitControl: []string{},
CommitControl: []string{},
TerminateControl: []string{},
+292 -308
View File
@@ -165,6 +165,298 @@ of automatically performing on-chain operations.`,
Comment: ``,
},
},
"CurioAddresses": {
{
Name: "PreCommitControl",
Type: "[]string",
Comment: `Addresses to send PreCommit messages from`,
},
{
Name: "CommitControl",
Type: "[]string",
Comment: `Addresses to send Commit messages from`,
},
{
Name: "TerminateControl",
Type: "[]string",
Comment: ``,
},
{
Name: "DisableOwnerFallback",
Type: "bool",
Comment: `DisableOwnerFallback disables usage of the owner address for messages
sent automatically`,
},
{
Name: "DisableWorkerFallback",
Type: "bool",
Comment: `DisableWorkerFallback disables usage of the worker address for messages
sent automatically, if control addresses are configured.
A control address that doesn't have enough funds will still be chosen
over the worker address if this flag is set.`,
},
{
Name: "MinerAddresses",
Type: "[]string",
Comment: `MinerAddresses are the addresses of the miner actors to use for sending messages`,
},
},
"CurioConfig": {
{
Name: "Subsystems",
Type: "CurioSubsystemsConfig",
Comment: ``,
},
{
Name: "Fees",
Type: "CurioFees",
Comment: ``,
},
{
Name: "Addresses",
Type: "[]CurioAddresses",
Comment: `Addresses of wallets per MinerAddress (one of the fields).`,
},
{
Name: "Proving",
Type: "ProvingConfig",
Comment: ``,
},
{
Name: "Journal",
Type: "JournalConfig",
Comment: ``,
},
{
Name: "Apis",
Type: "ApisConfig",
Comment: ``,
},
},
"CurioFees": {
{
Name: "DefaultMaxFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxPreCommitGasFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxCommitGasFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxPreCommitBatchGasFee",
Type: "BatchFeeConfig",
Comment: `maxBatchFee = maxBase + maxPerSector * nSectors`,
},
{
Name: "MaxCommitBatchGasFee",
Type: "BatchFeeConfig",
Comment: ``,
},
{
Name: "MaxTerminateGasFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxWindowPoStGasFee",
Type: "types.FIL",
Comment: `WindowPoSt is a high-value operation, so the default fee should be high.`,
},
{
Name: "MaxPublishDealsFee",
Type: "types.FIL",
Comment: ``,
},
},
"CurioSubsystemsConfig": {
{
Name: "EnableWindowPost",
Type: "bool",
Comment: `EnableWindowPost enables window post to be executed on this lotus-provider instance. Each machine in the cluster
with WindowPoSt enabled will also participate in the window post scheduler. It is possible to have multiple
machines with WindowPoSt enabled which will provide redundancy, and in case of multiple partitions per deadline,
will allow for parallel processing of partitions.
It is possible to have instances handling both WindowPoSt and WinningPoSt, which can provide redundancy without
the need for additional machines. In setups like this it is generally recommended to run
partitionsPerDeadline+1 machines.`,
},
{
Name: "WindowPostMaxTasks",
Type: "int",
Comment: ``,
},
{
Name: "EnableWinningPost",
Type: "bool",
Comment: `EnableWinningPost enables winning post to be executed on this lotus-provider instance.
Each machine in the cluster with WinningPoSt enabled will also participate in the winning post scheduler.
It is possible to mix machines with WindowPoSt and WinningPoSt enabled, for details see the EnableWindowPost
documentation.`,
},
{
Name: "WinningPostMaxTasks",
Type: "int",
Comment: ``,
},
{
Name: "EnableSealSDR",
Type: "bool",
Comment: `EnableSealSDR enables SDR tasks to run. SDR is the long sequential computation
creating 11 layer files in sector cache directory.
SDR is the first task in the sealing pipeline. It's inputs are just the hash of the
unsealed data (CommD), sector number, miner id, and the seal proof type.
It's outputs are the 11 layer files in the sector cache directory.
In lotus-miner this was run as part of PreCommit1.`,
},
{
Name: "SealSDRMaxTasks",
Type: "int",
Comment: `The maximum amount of SDR tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine.`,
},
{
Name: "EnableSealSDRTrees",
Type: "bool",
Comment: `EnableSealSDRTrees enables the SDR pipeline tree-building task to run.
This task handles encoding of unsealed data into last sdr layer and building
of TreeR, TreeC and TreeD.
This task runs after SDR
TreeD is first computed with optional input of unsealed data
TreeR is computed from replica, which is first computed as field
addition of the last SDR layer and the bottom layer of TreeD (which is the unsealed data)
TreeC is computed from the 11 SDR layers
The 3 trees will later be used to compute the PoRep proof.
In case of SyntheticPoRep challenges for PoRep will be pre-generated at this step, and trees and layers
will be dropped. SyntheticPoRep works by pre-generating a very large set of challenges (~30GiB on disk)
then using a small subset of them for the actual PoRep computation. This allows for significant scratch space
saving between PreCommit and PoRep generation at the expense of more computation (generating challenges in this step)
In lotus-miner this was run as part of PreCommit2 (TreeD was run in PreCommit1).
Note that nodes with SDRTrees enabled will also answer to Finalize tasks,
which just remove unneeded tree data after PoRep is computed.`,
},
{
Name: "SealSDRTreesMaxTasks",
Type: "int",
Comment: `The maximum amount of SealSDRTrees tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine.`,
},
{
Name: "FinalizeMaxTasks",
Type: "int",
Comment: `FinalizeMaxTasks is the maximum amount of finalize tasks that can run simultaneously.
The finalize task is enabled on all machines which also handle SDRTrees tasks. Finalize ALWAYS runs on whichever
machine holds sector cache files, as it removes unneeded tree data after PoRep is computed.
Finalize will run in parallel with the SubmitCommitMsg task.`,
},
{
Name: "EnableSendPrecommitMsg",
Type: "bool",
Comment: `EnableSendPrecommitMsg enables the sending of precommit messages to the chain
from this lotus-provider instance.
This runs after SDRTrees and uses the output CommD / CommR (roots of TreeD / TreeR) for the message`,
},
{
Name: "EnablePoRepProof",
Type: "bool",
Comment: `EnablePoRepProof enables the computation of the porep proof
This task runs after interactive-porep seed becomes available, which happens 150 epochs (75min) after the
precommit message lands on chain. This task should run on a machine with a GPU. Vanilla PoRep proofs are
requested from the machine which holds sector cache files which most likely is the machine which ran the SDRTrees
task.
In lotus-miner this was Commit1 / Commit2`,
},
{
Name: "PoRepProofMaxTasks",
Type: "int",
Comment: `The maximum amount of PoRepProof tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine.`,
},
{
Name: "EnableSendCommitMsg",
Type: "bool",
Comment: `EnableSendCommitMsg enables the sending of commit messages to the chain
from this lotus-provider instance.`,
},
{
Name: "EnableMoveStorage",
Type: "bool",
Comment: `EnableMoveStorage enables the move-into-long-term-storage task to run on this lotus-provider instance.
This tasks should only be enabled on nodes with long-term storage.
The MoveStorage task is the last task in the sealing pipeline. It moves the sealed sector data from the
SDRTrees machine into long-term storage. This task runs after the Finalize task.`,
},
{
Name: "MoveStorageMaxTasks",
Type: "int",
Comment: `The maximum amount of MoveStorage tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine. It is recommended that this value is set to a number which
uses all available network (or disk) bandwidth on the machine without causing bottlenecks.`,
},
{
Name: "EnableWebGui",
Type: "bool",
Comment: `EnableWebGui enables the web GUI on this lotus-provider instance. The UI has minimal local overhead, but it should
only need to be run on a single machine in the cluster.`,
},
{
Name: "GuiAddress",
Type: "string",
Comment: `The address that should listen for Web GUI requests.`,
},
},
"DAGStoreConfig": {
{
Name: "RootDir",
@@ -699,136 +991,6 @@ closed by the connection manager.`,
Comment: `SubsystemLevels specify per-subsystem log levels`,
},
},
"LotusProviderAddresses": {
{
Name: "PreCommitControl",
Type: "[]string",
Comment: `Addresses to send PreCommit messages from`,
},
{
Name: "CommitControl",
Type: "[]string",
Comment: `Addresses to send Commit messages from`,
},
{
Name: "TerminateControl",
Type: "[]string",
Comment: ``,
},
{
Name: "DisableOwnerFallback",
Type: "bool",
Comment: `DisableOwnerFallback disables usage of the owner address for messages
sent automatically`,
},
{
Name: "DisableWorkerFallback",
Type: "bool",
Comment: `DisableWorkerFallback disables usage of the worker address for messages
sent automatically, if control addresses are configured.
A control address that doesn't have enough funds will still be chosen
over the worker address if this flag is set.`,
},
{
Name: "MinerAddresses",
Type: "[]string",
Comment: `MinerAddresses are the addresses of the miner actors to use for sending messages`,
},
},
"LotusProviderConfig": {
{
Name: "Subsystems",
Type: "ProviderSubsystemsConfig",
Comment: ``,
},
{
Name: "Fees",
Type: "LotusProviderFees",
Comment: ``,
},
{
Name: "Addresses",
Type: "[]LotusProviderAddresses",
Comment: `Addresses of wallets per MinerAddress (one of the fields).`,
},
{
Name: "Proving",
Type: "ProvingConfig",
Comment: ``,
},
{
Name: "Journal",
Type: "JournalConfig",
Comment: ``,
},
{
Name: "Apis",
Type: "ApisConfig",
Comment: ``,
},
},
"LotusProviderFees": {
{
Name: "DefaultMaxFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxPreCommitGasFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxCommitGasFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxPreCommitBatchGasFee",
Type: "BatchFeeConfig",
Comment: `maxBatchFee = maxBase + maxPerSector * nSectors`,
},
{
Name: "MaxCommitBatchGasFee",
Type: "BatchFeeConfig",
Comment: ``,
},
{
Name: "MaxTerminateGasFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxWindowPoStGasFee",
Type: "types.FIL",
Comment: `WindowPoSt is a high-value operation, so the default fee should be high.`,
},
{
Name: "MaxPublishDealsFee",
Type: "types.FIL",
Comment: ``,
},
},
"MinerAddressConfig": {
{
Name: "PreCommitControl",
@@ -998,184 +1160,6 @@ When disabled and no external block producers are configured, all potential
block rewards will be missed!`,
},
},
"ProviderSubsystemsConfig": {
{
Name: "EnableWindowPost",
Type: "bool",
Comment: `EnableWindowPost enables window post to be executed on this lotus-provider instance. Each machine in the cluster
with WindowPoSt enabled will also participate in the window post scheduler. It is possible to have multiple
machines with WindowPoSt enabled which will provide redundancy, and in case of multiple partitions per deadline,
will allow for parallel processing of partitions.
It is possible to have instances handling both WindowPoSt and WinningPoSt, which can provide redundancy without
the need for additional machines. In setups like this it is generally recommended to run
partitionsPerDeadline+1 machines.`,
},
{
Name: "WindowPostMaxTasks",
Type: "int",
Comment: ``,
},
{
Name: "EnableWinningPost",
Type: "bool",
Comment: `EnableWinningPost enables winning post to be executed on this lotus-provider instance.
Each machine in the cluster with WinningPoSt enabled will also participate in the winning post scheduler.
It is possible to mix machines with WindowPoSt and WinningPoSt enabled, for details see the EnableWindowPost
documentation.`,
},
{
Name: "WinningPostMaxTasks",
Type: "int",
Comment: ``,
},
{
Name: "EnableParkPiece",
Type: "bool",
Comment: `EnableParkPiece enables the "piece parking" task to run on this node. This task is responsible for fetching
pieces from the network and storing them in the storage subsystem until sectors are sealed. This task is
only applicable when integrating with boost, and should be enabled on nodes which will hold deal data
from boost until sectors containing the related pieces have the TreeD/TreeR constructed.
Note that future Curio implementations will have a separate task type for fetching pieces from the internet.`,
},
{
Name: "ParkPieceMaxTasks",
Type: "int",
Comment: ``,
},
{
Name: "EnableSealSDR",
Type: "bool",
Comment: `EnableSealSDR enables SDR tasks to run. SDR is the long sequential computation
creating 11 layer files in sector cache directory.
SDR is the first task in the sealing pipeline. It's inputs are just the hash of the
unsealed data (CommD), sector number, miner id, and the seal proof type.
It's outputs are the 11 layer files in the sector cache directory.
In lotus-miner this was run as part of PreCommit1.`,
},
{
Name: "SealSDRMaxTasks",
Type: "int",
Comment: `The maximum amount of SDR tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine.`,
},
{
Name: "EnableSealSDRTrees",
Type: "bool",
Comment: `EnableSealSDRTrees enables the SDR pipeline tree-building task to run.
This task handles encoding of unsealed data into last sdr layer and building
of TreeR, TreeC and TreeD.
This task runs after SDR
TreeD is first computed with optional input of unsealed data
TreeR is computed from replica, which is first computed as field
addition of the last SDR layer and the bottom layer of TreeD (which is the unsealed data)
TreeC is computed from the 11 SDR layers
The 3 trees will later be used to compute the PoRep proof.
In case of SyntheticPoRep challenges for PoRep will be pre-generated at this step, and trees and layers
will be dropped. SyntheticPoRep works by pre-generating a very large set of challenges (~30GiB on disk)
then using a small subset of them for the actual PoRep computation. This allows for significant scratch space
saving between PreCommit and PoRep generation at the expense of more computation (generating challenges in this step)
In lotus-miner this was run as part of PreCommit2 (TreeD was run in PreCommit1).
Note that nodes with SDRTrees enabled will also answer to Finalize tasks,
which just remove unneeded tree data after PoRep is computed.`,
},
{
Name: "SealSDRTreesMaxTasks",
Type: "int",
Comment: `The maximum amount of SealSDRTrees tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine.`,
},
{
Name: "FinalizeMaxTasks",
Type: "int",
Comment: `FinalizeMaxTasks is the maximum amount of finalize tasks that can run simultaneously.
The finalize task is enabled on all machines which also handle SDRTrees tasks. Finalize ALWAYS runs on whichever
machine holds sector cache files, as it removes unneeded tree data after PoRep is computed.
Finalize will run in parallel with the SubmitCommitMsg task.`,
},
{
Name: "EnableSendPrecommitMsg",
Type: "bool",
Comment: `EnableSendPrecommitMsg enables the sending of precommit messages to the chain
from this lotus-provider instance.
This runs after SDRTrees and uses the output CommD / CommR (roots of TreeD / TreeR) for the message`,
},
{
Name: "EnablePoRepProof",
Type: "bool",
Comment: `EnablePoRepProof enables the computation of the porep proof
This task runs after interactive-porep seed becomes available, which happens 150 epochs (75min) after the
precommit message lands on chain. This task should run on a machine with a GPU. Vanilla PoRep proofs are
requested from the machine which holds sector cache files which most likely is the machine which ran the SDRTrees
task.
In lotus-miner this was Commit1 / Commit2`,
},
{
Name: "PoRepProofMaxTasks",
Type: "int",
Comment: `The maximum amount of PoRepProof tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine.`,
},
{
Name: "EnableSendCommitMsg",
Type: "bool",
Comment: `EnableSendCommitMsg enables the sending of commit messages to the chain
from this lotus-provider instance.`,
},
{
Name: "EnableMoveStorage",
Type: "bool",
Comment: `EnableMoveStorage enables the move-into-long-term-storage task to run on this lotus-provider instance.
This tasks should only be enabled on nodes with long-term storage.
The MoveStorage task is the last task in the sealing pipeline. It moves the sealed sector data from the
SDRTrees machine into long-term storage. This task runs after the Finalize task.`,
},
{
Name: "MoveStorageMaxTasks",
Type: "int",
Comment: `The maximum amount of MoveStorage tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine. It is recommended that this value is set to a number which
uses all available network (or disk) bandwidth on the machine without causing bottlenecks.`,
},
{
Name: "EnableWebGui",
Type: "bool",
Comment: `EnableWebGui enables the web GUI on this lotus-provider instance. The UI has minimal local overhead, but it should
only need to be run on a single machine in the cluster.`,
},
{
Name: "GuiAddress",
Type: "string",
Comment: `The address that should listen for Web GUI requests.`,
},
},
"ProvingConfig": {
{
Name: "ParallelCheckLimit",
+2 -1
View File
@@ -266,6 +266,7 @@ func ConfigUpdate(cfgCur, cfgDef interface{}, opts ...UpdateCfgOpt) ([]byte, err
}
// sanity-check that the updated config parses the same way as the current one
if cfgDef != nil {
cfgUpdated, err := FromReader(strings.NewReader(nodeStr), cfgDef)
if err != nil {
@@ -273,7 +274,7 @@ func ConfigUpdate(cfgCur, cfgDef interface{}, opts ...UpdateCfgOpt) ([]byte, err
}
if !reflect.DeepEqual(cfgCur, cfgUpdated) {
return nil, xerrors.Errorf("updated config didn't match current config")
return nil, xerrors.Errorf("updated config didn't match current config:")
}
}
+7 -7
View File
@@ -66,13 +66,13 @@ type StorageMiner struct {
HarmonyDB HarmonyDB
}
type LotusProviderConfig struct {
Subsystems ProviderSubsystemsConfig
type CurioConfig struct {
Subsystems CurioSubsystemsConfig
Fees LotusProviderFees
Fees CurioFees
// Addresses of wallets per MinerAddress (one of the fields).
Addresses []LotusProviderAddresses
Addresses []CurioAddresses
Proving ProvingConfig
Journal JournalConfig
Apis ApisConfig
@@ -93,7 +93,7 @@ type JournalConfig struct {
DisabledEvents string
}
type ProviderSubsystemsConfig struct {
type CurioSubsystemsConfig struct {
// EnableWindowPost enables window post to be executed on this lotus-provider instance. Each machine in the cluster
// with WindowPoSt enabled will also participate in the window post scheduler. It is possible to have multiple
// machines with WindowPoSt enabled which will provide redundancy, and in case of multiple partitions per deadline,
@@ -671,7 +671,7 @@ type MinerFeeConfig struct {
MaximizeWindowPoStFeeCap bool
}
type LotusProviderFees struct {
type CurioFees struct {
DefaultMaxFee types.FIL
MaxPreCommitGasFee types.FIL
MaxCommitGasFee types.FIL
@@ -703,7 +703,7 @@ type MinerAddressConfig struct {
DisableWorkerFallback bool
}
type LotusProviderAddresses struct {
type CurioAddresses struct {
// Addresses to send PreCommit messages from
PreCommitControl []string
// Addresses to send Commit messages from