chore: curio: remove forgotten parts of curio config (#12087)
This commit is contained in:
Peter Rabbitson
GitHub
parent
cea71aef51
commit
63b95779ce
3
.github/workflows/test.yml
vendored
3
.github/workflows/test.yml
vendored
@ -147,8 +147,7 @@ jobs:
|
||||
"itest-worker",
|
||||
"multicore-sdr",
|
||||
"unit-cli",
|
||||
"unit-storage",
|
||||
"itest-curio"
|
||||
"unit-storage"
|
||||
]
|
||||
run: |
|
||||
# Create a list of integration test groups
|
||||
|
||||
1
.gitignore
vendored
1
.gitignore
vendored
@ -6,7 +6,6 @@
|
||||
/lotus-chainwatch
|
||||
/lotus-shed
|
||||
/lotus-sim
|
||||
/curio
|
||||
/sptool
|
||||
/lotus-townhall
|
||||
/lotus-fountain
|
||||
|
||||
@ -117,509 +117,6 @@ your node if metadata log is disabled`,
|
||||
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`,
|
||||
},
|
||||
},
|
||||
"CurioAlerting": {
|
||||
{
|
||||
Name: "PagerDutyEventURL",
|
||||
Type: "string",
|
||||
|
||||
Comment: `PagerDutyEventURL is URL for PagerDuty.com Events API v2 URL. Events sent to this API URL are ultimately
|
||||
routed to a PagerDuty.com service and processed.
|
||||
The default is sufficient for integration with the stock commercial PagerDuty.com company's service.`,
|
||||
},
|
||||
{
|
||||
Name: "PageDutyIntegrationKey",
|
||||
Type: "string",
|
||||
|
||||
Comment: `PageDutyIntegrationKey is the integration key for a PagerDuty.com service. You can find this unique service
|
||||
identifier in the integration page for the service.`,
|
||||
},
|
||||
{
|
||||
Name: "MinimumWalletBalance",
|
||||
Type: "types.FIL",
|
||||
|
||||
Comment: `MinimumWalletBalance is the minimum balance all active wallets. If the balance is below this value, an
|
||||
alerts will be triggered for the wallet`,
|
||||
},
|
||||
},
|
||||
"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: "CurioProvingConfig",
|
||||
|
||||
Comment: ``,
|
||||
},
|
||||
{
|
||||
Name: "Ingest",
|
||||
Type: "CurioIngestConfig",
|
||||
|
||||
Comment: ``,
|
||||
},
|
||||
{
|
||||
Name: "Journal",
|
||||
Type: "JournalConfig",
|
||||
|
||||
Comment: ``,
|
||||
},
|
||||
{
|
||||
Name: "Apis",
|
||||
Type: "ApisConfig",
|
||||
|
||||
Comment: ``,
|
||||
},
|
||||
{
|
||||
Name: "Alerting",
|
||||
Type: "CurioAlerting",
|
||||
|
||||
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: ``,
|
||||
},
|
||||
},
|
||||
"CurioIngestConfig": {
|
||||
{
|
||||
Name: "MaxQueueSDR",
|
||||
Type: "int",
|
||||
|
||||
Comment: `Maximum number of sectors that can be queued waiting for SDR to start processing.
|
||||
0 = unlimited
|
||||
Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
|
||||
The SDR queue includes deals which are in the process of entering the sealing pipeline - size of this queue
|
||||
will also impact the maximum number of ParkPiece tasks which can run concurrently.
|
||||
|
||||
SDR queue is the first queue in the sealing pipeline, meaning that it should be used as the primary backpressure mechanism.`,
|
||||
},
|
||||
{
|
||||
Name: "MaxQueueTrees",
|
||||
Type: "int",
|
||||
|
||||
Comment: `Maximum number of sectors that can be queued waiting for SDRTrees to start processing.
|
||||
0 = unlimited
|
||||
Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
|
||||
In case of the trees tasks it is possible that this queue grows more than this limit, the backpressure is only
|
||||
applied to sectors entering the pipeline.`,
|
||||
},
|
||||
{
|
||||
Name: "MaxQueuePoRep",
|
||||
Type: "int",
|
||||
|
||||
Comment: `Maximum number of sectors that can be queued waiting for PoRep to start processing.
|
||||
0 = unlimited
|
||||
Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
|
||||
Like with the trees tasks, it is possible that this queue grows more than this limit, the backpressure is only
|
||||
applied to sectors entering the pipeline.`,
|
||||
},
|
||||
},
|
||||
"CurioProvingConfig": {
|
||||
{
|
||||
Name: "ParallelCheckLimit",
|
||||
Type: "int",
|
||||
|
||||
Comment: `Maximum number of sector checks to run in parallel. (0 = unlimited)
|
||||
|
||||
WARNING: Setting this value too high may make the node crash by running out of stack
|
||||
WARNING: Setting this value too low may make sector challenge reading much slower, resulting in failed PoSt due
|
||||
to late submission.
|
||||
|
||||
After changing this option, confirm that the new value works in your setup by invoking
|
||||
'lotus-miner proving compute window-post 0'`,
|
||||
},
|
||||
{
|
||||
Name: "SingleCheckTimeout",
|
||||
Type: "Duration",
|
||||
|
||||
Comment: `Maximum amount of time a proving pre-check can take for a sector. If the check times out the sector will be skipped
|
||||
|
||||
WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the
|
||||
test challenge took longer than this timeout
|
||||
WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this sector are
|
||||
blocked (e.g. in case of disconnected NFS mount)`,
|
||||
},
|
||||
{
|
||||
Name: "PartitionCheckTimeout",
|
||||
Type: "Duration",
|
||||
|
||||
Comment: `Maximum amount of time a proving pre-check can take for an entire partition. If the check times out, sectors in
|
||||
the partition which didn't get checked on time will be skipped
|
||||
|
||||
WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the
|
||||
test challenge took longer than this timeout
|
||||
WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this partition are
|
||||
blocked or slow`,
|
||||
},
|
||||
{
|
||||
Name: "DisableWDPoStPreChecks",
|
||||
Type: "bool",
|
||||
|
||||
Comment: `Disable WindowPoSt provable sector readability checks.
|
||||
|
||||
In normal operation, when preparing to compute WindowPoSt, lotus-miner will perform a round of reading challenges
|
||||
from all sectors to confirm that those sectors can be proven. Challenges read in this process are discarded, as
|
||||
we're only interested in checking that sector data can be read.
|
||||
|
||||
When using builtin proof computation (no PoSt workers, and DisableBuiltinWindowPoSt is set to false), this process
|
||||
can save a lot of time and compute resources in the case that some sectors are not readable - this is caused by
|
||||
the builtin logic not skipping snark computation when some sectors need to be skipped.
|
||||
|
||||
When using PoSt workers, this process is mostly redundant, with PoSt workers challenges will be read once, and
|
||||
if challenges for some sectors aren't readable, those sectors will just get skipped.
|
||||
|
||||
Disabling sector pre-checks will slightly reduce IO load when proving sectors, possibly resulting in shorter
|
||||
time to produce window PoSt. In setups with good IO capabilities the effect of this option on proving time should
|
||||
be negligible.
|
||||
|
||||
NOTE: It likely is a bad idea to disable sector pre-checks in setups with no PoSt workers.
|
||||
|
||||
NOTE: Even when this option is enabled, recovering sectors will be checked before recovery declaration message is
|
||||
sent to the chain
|
||||
|
||||
After changing this option, confirm that the new value works in your setup by invoking
|
||||
'lotus-miner proving compute window-post 0'`,
|
||||
},
|
||||
{
|
||||
Name: "MaxPartitionsPerPoStMessage",
|
||||
Type: "int",
|
||||
|
||||
Comment: `Maximum number of partitions to prove in a single SubmitWindowPoSt messace. 0 = network limit (3 in nv21)
|
||||
|
||||
A single partition may contain up to 2349 32GiB sectors, or 2300 64GiB sectors.
|
||||
//
|
||||
Note that setting this value lower may result in less efficient gas use - more messages will be sent,
|
||||
to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)
|
||||
|
||||
Setting this value above the network limit has no effect`,
|
||||
},
|
||||
{
|
||||
Name: "MaxPartitionsPerRecoveryMessage",
|
||||
Type: "int",
|
||||
|
||||
Comment: `In some cases when submitting DeclareFaultsRecovered messages,
|
||||
there may be too many recoveries to fit in a BlockGasLimit.
|
||||
In those cases it may be necessary to set this value to something low (eg 1);
|
||||
Note that setting this value lower may result in less efficient gas use - more messages will be sent than needed,
|
||||
resulting in more total gas use (but each message will have lower gas limit)`,
|
||||
},
|
||||
{
|
||||
Name: "SingleRecoveringPartitionPerPostMessage",
|
||||
Type: "bool",
|
||||
|
||||
Comment: `Enable single partition per PoSt Message for partitions containing recovery sectors
|
||||
|
||||
In cases when submitting PoSt messages which contain recovering sectors, the default network limit may still be
|
||||
too high to fit in the block gas limit. In those cases, it becomes useful to only house the single partition
|
||||
with recovering sectors in the post message
|
||||
|
||||
Note that setting this value lower may result in less efficient gas use - more messages will be sent,
|
||||
to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)`,
|
||||
},
|
||||
},
|
||||
"CurioSubsystemsConfig": {
|
||||
{
|
||||
Name: "EnableWindowPost",
|
||||
Type: "bool",
|
||||
|
||||
Comment: `EnableWindowPost enables window post to be executed on this curio 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 curio 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 curio 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 curio instance.`,
|
||||
},
|
||||
{
|
||||
Name: "EnableMoveStorage",
|
||||
Type: "bool",
|
||||
|
||||
Comment: `EnableMoveStorage enables the move-into-long-term-storage task to run on this curio 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: "BoostAdapters",
|
||||
Type: "[]string",
|
||||
|
||||
Comment: `BoostAdapters is a list of tuples of miner address and port/ip to listen for market (e.g. boost) requests.
|
||||
This interface is compatible with the lotus-miner RPC, implementing a subset needed for storage market operations.
|
||||
Strings should be in the format "actor:ip:port". IP cannot be 0.0.0.0. We recommend using a private IP.
|
||||
Example: "f0123:127.0.0.1:32100". Multiple addresses can be specified.
|
||||
|
||||
When a market node like boost gives Curio's market RPC a deal to placing into a sector, Curio will first store the
|
||||
deal data in a temporary location "Piece Park" before assigning it to a sector. This requires that at least one
|
||||
node in the cluster has the EnableParkPiece option enabled and has sufficient scratch space to store the deal data.
|
||||
This is different from lotus-miner which stored the deal data into an "unsealed" sector as soon as the deal was
|
||||
received. Deal data in PiecePark is accessed when the sector TreeD and TreeR are computed, but isn't needed for
|
||||
the initial SDR layers computation. Pieces in PiecePark are removed after all sectors referencing the piece are
|
||||
sealed.
|
||||
|
||||
To get API info for boost configuration run 'curio market rpc-info'
|
||||
|
||||
NOTE: All deal data will flow through this service, so it should be placed on a machine running boost or on
|
||||
a machine which handles ParkPiece tasks.`,
|
||||
},
|
||||
{
|
||||
Name: "EnableWebGui",
|
||||
Type: "bool",
|
||||
|
||||
Comment: `EnableWebGui enables the web GUI on this curio 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.`,
|
||||
},
|
||||
},
|
||||
"DealmakingConfig": {
|
||||
{
|
||||
Name: "StartEpochSealingBuffer",
|
||||
|
||||
@ -60,20 +60,6 @@ type StorageMiner struct {
|
||||
HarmonyDB HarmonyDB
|
||||
}
|
||||
|
||||
type CurioConfig struct {
|
||||
Subsystems CurioSubsystemsConfig
|
||||
|
||||
Fees CurioFees
|
||||
|
||||
// Addresses of wallets per MinerAddress (one of the fields).
|
||||
Addresses []CurioAddresses
|
||||
Proving CurioProvingConfig
|
||||
Ingest CurioIngestConfig
|
||||
Journal JournalConfig
|
||||
Apis ApisConfig
|
||||
Alerting CurioAlerting
|
||||
}
|
||||
|
||||
type ApisConfig struct {
|
||||
// ChainApiInfo is the API endpoint for the Lotus daemon.
|
||||
ChainApiInfo []string
|
||||
@ -89,140 +75,6 @@ type JournalConfig struct {
|
||||
DisabledEvents string
|
||||
}
|
||||
|
||||
type CurioSubsystemsConfig struct {
|
||||
// EnableWindowPost enables window post to be executed on this curio 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.
|
||||
EnableWindowPost bool
|
||||
WindowPostMaxTasks int
|
||||
|
||||
// EnableWinningPost enables winning post to be executed on this curio 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.
|
||||
EnableWinningPost bool
|
||||
WinningPostMaxTasks int
|
||||
|
||||
// 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.
|
||||
EnableParkPiece bool
|
||||
ParkPieceMaxTasks int
|
||||
|
||||
// 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.
|
||||
EnableSealSDR bool
|
||||
|
||||
// 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.
|
||||
SealSDRMaxTasks int
|
||||
|
||||
// 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.
|
||||
EnableSealSDRTrees bool
|
||||
|
||||
// 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.
|
||||
SealSDRTreesMaxTasks int
|
||||
|
||||
// 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.
|
||||
FinalizeMaxTasks int
|
||||
|
||||
// EnableSendPrecommitMsg enables the sending of precommit messages to the chain
|
||||
// from this curio instance.
|
||||
// This runs after SDRTrees and uses the output CommD / CommR (roots of TreeD / TreeR) for the message
|
||||
EnableSendPrecommitMsg bool
|
||||
|
||||
// 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
|
||||
EnablePoRepProof bool
|
||||
|
||||
// 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.
|
||||
PoRepProofMaxTasks int
|
||||
|
||||
// EnableSendCommitMsg enables the sending of commit messages to the chain
|
||||
// from this curio instance.
|
||||
EnableSendCommitMsg bool
|
||||
|
||||
// EnableMoveStorage enables the move-into-long-term-storage task to run on this curio 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.
|
||||
EnableMoveStorage bool
|
||||
|
||||
// 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.
|
||||
MoveStorageMaxTasks int
|
||||
|
||||
// BoostAdapters is a list of tuples of miner address and port/ip to listen for market (e.g. boost) requests.
|
||||
// This interface is compatible with the lotus-miner RPC, implementing a subset needed for storage market operations.
|
||||
// Strings should be in the format "actor:ip:port". IP cannot be 0.0.0.0. We recommend using a private IP.
|
||||
// Example: "f0123:127.0.0.1:32100". Multiple addresses can be specified.
|
||||
//
|
||||
// When a market node like boost gives Curio's market RPC a deal to placing into a sector, Curio will first store the
|
||||
// deal data in a temporary location "Piece Park" before assigning it to a sector. This requires that at least one
|
||||
// node in the cluster has the EnableParkPiece option enabled and has sufficient scratch space to store the deal data.
|
||||
// This is different from lotus-miner which stored the deal data into an "unsealed" sector as soon as the deal was
|
||||
// received. Deal data in PiecePark is accessed when the sector TreeD and TreeR are computed, but isn't needed for
|
||||
// the initial SDR layers computation. Pieces in PiecePark are removed after all sectors referencing the piece are
|
||||
// sealed.
|
||||
//
|
||||
// To get API info for boost configuration run 'curio market rpc-info'
|
||||
//
|
||||
// NOTE: All deal data will flow through this service, so it should be placed on a machine running boost or on
|
||||
// a machine which handles ParkPiece tasks.
|
||||
BoostAdapters []string
|
||||
|
||||
// EnableWebGui enables the web GUI on this curio instance. The UI has minimal local overhead, but it should
|
||||
// only need to be run on a single machine in the cluster.
|
||||
EnableWebGui bool
|
||||
|
||||
// The address that should listen for Web GUI requests.
|
||||
GuiAddress string
|
||||
}
|
||||
|
||||
type MinerSubsystemConfig struct {
|
||||
EnableMining bool
|
||||
EnableSealing bool
|
||||
@ -543,20 +395,6 @@ type MinerFeeConfig struct {
|
||||
MaximizeWindowPoStFeeCap bool
|
||||
}
|
||||
|
||||
type CurioFees struct {
|
||||
DefaultMaxFee types.FIL
|
||||
MaxPreCommitGasFee types.FIL
|
||||
MaxCommitGasFee types.FIL
|
||||
|
||||
// maxBatchFee = maxBase + maxPerSector * nSectors
|
||||
MaxPreCommitBatchGasFee BatchFeeConfig
|
||||
MaxCommitBatchGasFee BatchFeeConfig
|
||||
|
||||
MaxTerminateGasFee types.FIL
|
||||
// WindowPoSt is a high-value operation, so the default fee should be high.
|
||||
MaxWindowPoStGasFee types.FIL
|
||||
MaxPublishDealsFee types.FIL
|
||||
}
|
||||
type MinerAddressConfig struct {
|
||||
// Addresses to send PreCommit messages from
|
||||
PreCommitControl []string
|
||||
@ -575,135 +413,6 @@ type MinerAddressConfig struct {
|
||||
DisableWorkerFallback bool
|
||||
}
|
||||
|
||||
type CurioAddresses struct {
|
||||
// Addresses to send PreCommit messages from
|
||||
PreCommitControl []string
|
||||
// Addresses to send Commit messages from
|
||||
CommitControl []string
|
||||
TerminateControl []string
|
||||
|
||||
// DisableOwnerFallback disables usage of the owner address for messages
|
||||
// sent automatically
|
||||
DisableOwnerFallback bool
|
||||
// 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.
|
||||
DisableWorkerFallback bool
|
||||
|
||||
// MinerAddresses are the addresses of the miner actors to use for sending messages
|
||||
MinerAddresses []string
|
||||
}
|
||||
|
||||
type CurioProvingConfig struct {
|
||||
// Maximum number of sector checks to run in parallel. (0 = unlimited)
|
||||
//
|
||||
// WARNING: Setting this value too high may make the node crash by running out of stack
|
||||
// WARNING: Setting this value too low may make sector challenge reading much slower, resulting in failed PoSt due
|
||||
// to late submission.
|
||||
//
|
||||
// After changing this option, confirm that the new value works in your setup by invoking
|
||||
// 'lotus-miner proving compute window-post 0'
|
||||
ParallelCheckLimit int
|
||||
|
||||
// Maximum amount of time a proving pre-check can take for a sector. If the check times out the sector will be skipped
|
||||
//
|
||||
// WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the
|
||||
// test challenge took longer than this timeout
|
||||
// WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this sector are
|
||||
// blocked (e.g. in case of disconnected NFS mount)
|
||||
SingleCheckTimeout Duration
|
||||
|
||||
// Maximum amount of time a proving pre-check can take for an entire partition. If the check times out, sectors in
|
||||
// the partition which didn't get checked on time will be skipped
|
||||
//
|
||||
// WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the
|
||||
// test challenge took longer than this timeout
|
||||
// WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this partition are
|
||||
// blocked or slow
|
||||
PartitionCheckTimeout Duration
|
||||
|
||||
// Disable WindowPoSt provable sector readability checks.
|
||||
//
|
||||
// In normal operation, when preparing to compute WindowPoSt, lotus-miner will perform a round of reading challenges
|
||||
// from all sectors to confirm that those sectors can be proven. Challenges read in this process are discarded, as
|
||||
// we're only interested in checking that sector data can be read.
|
||||
//
|
||||
// When using builtin proof computation (no PoSt workers, and DisableBuiltinWindowPoSt is set to false), this process
|
||||
// can save a lot of time and compute resources in the case that some sectors are not readable - this is caused by
|
||||
// the builtin logic not skipping snark computation when some sectors need to be skipped.
|
||||
//
|
||||
// When using PoSt workers, this process is mostly redundant, with PoSt workers challenges will be read once, and
|
||||
// if challenges for some sectors aren't readable, those sectors will just get skipped.
|
||||
//
|
||||
// Disabling sector pre-checks will slightly reduce IO load when proving sectors, possibly resulting in shorter
|
||||
// time to produce window PoSt. In setups with good IO capabilities the effect of this option on proving time should
|
||||
// be negligible.
|
||||
//
|
||||
// NOTE: It likely is a bad idea to disable sector pre-checks in setups with no PoSt workers.
|
||||
//
|
||||
// NOTE: Even when this option is enabled, recovering sectors will be checked before recovery declaration message is
|
||||
// sent to the chain
|
||||
//
|
||||
// After changing this option, confirm that the new value works in your setup by invoking
|
||||
// 'lotus-miner proving compute window-post 0'
|
||||
DisableWDPoStPreChecks bool
|
||||
|
||||
// Maximum number of partitions to prove in a single SubmitWindowPoSt messace. 0 = network limit (3 in nv21)
|
||||
//
|
||||
// A single partition may contain up to 2349 32GiB sectors, or 2300 64GiB sectors.
|
||||
// //
|
||||
// Note that setting this value lower may result in less efficient gas use - more messages will be sent,
|
||||
// to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)
|
||||
//
|
||||
// Setting this value above the network limit has no effect
|
||||
MaxPartitionsPerPoStMessage int
|
||||
|
||||
// Maximum number of partitions to declare in a single DeclareFaultsRecovered message. 0 = no limit.
|
||||
|
||||
// In some cases when submitting DeclareFaultsRecovered messages,
|
||||
// there may be too many recoveries to fit in a BlockGasLimit.
|
||||
// In those cases it may be necessary to set this value to something low (eg 1);
|
||||
// Note that setting this value lower may result in less efficient gas use - more messages will be sent than needed,
|
||||
// resulting in more total gas use (but each message will have lower gas limit)
|
||||
MaxPartitionsPerRecoveryMessage int
|
||||
|
||||
// Enable single partition per PoSt Message for partitions containing recovery sectors
|
||||
//
|
||||
// In cases when submitting PoSt messages which contain recovering sectors, the default network limit may still be
|
||||
// too high to fit in the block gas limit. In those cases, it becomes useful to only house the single partition
|
||||
// with recovering sectors in the post message
|
||||
//
|
||||
// Note that setting this value lower may result in less efficient gas use - more messages will be sent,
|
||||
// to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)
|
||||
SingleRecoveringPartitionPerPostMessage bool
|
||||
}
|
||||
|
||||
type CurioIngestConfig struct {
|
||||
// Maximum number of sectors that can be queued waiting for SDR to start processing.
|
||||
// 0 = unlimited
|
||||
// Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
|
||||
// The SDR queue includes deals which are in the process of entering the sealing pipeline - size of this queue
|
||||
// will also impact the maximum number of ParkPiece tasks which can run concurrently.
|
||||
//
|
||||
// SDR queue is the first queue in the sealing pipeline, meaning that it should be used as the primary backpressure mechanism.
|
||||
MaxQueueSDR int
|
||||
|
||||
// Maximum number of sectors that can be queued waiting for SDRTrees to start processing.
|
||||
// 0 = unlimited
|
||||
// Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
|
||||
// In case of the trees tasks it is possible that this queue grows more than this limit, the backpressure is only
|
||||
// applied to sectors entering the pipeline.
|
||||
MaxQueueTrees int
|
||||
|
||||
// Maximum number of sectors that can be queued waiting for PoRep to start processing.
|
||||
// 0 = unlimited
|
||||
// Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
|
||||
// Like with the trees tasks, it is possible that this queue grows more than this limit, the backpressure is only
|
||||
// applied to sectors entering the pipeline.
|
||||
MaxQueuePoRep int
|
||||
}
|
||||
|
||||
// API contains configs for API endpoint
|
||||
type API struct {
|
||||
// Binding address for the Lotus API
|
||||
@ -947,18 +656,3 @@ type FaultReporterConfig struct {
|
||||
// rewards. This address should have adequate funds to cover gas fees.
|
||||
ConsensusFaultReporterAddress string
|
||||
}
|
||||
|
||||
type CurioAlerting struct {
|
||||
// PagerDutyEventURL is URL for PagerDuty.com Events API v2 URL. Events sent to this API URL are ultimately
|
||||
// routed to a PagerDuty.com service and processed.
|
||||
// The default is sufficient for integration with the stock commercial PagerDuty.com company's service.
|
||||
PagerDutyEventURL string
|
||||
|
||||
// PageDutyIntegrationKey is the integration key for a PagerDuty.com service. You can find this unique service
|
||||
// identifier in the integration page for the service.
|
||||
PageDutyIntegrationKey string
|
||||
|
||||
// MinimumWalletBalance is the minimum balance all active wallets. If the balance is below this value, an
|
||||
// alerts will be triggered for the wallet
|
||||
MinimumWalletBalance types.FIL
|
||||
}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user