diff --git a/config/_default/menus/menus.en.toml b/config/_default/menus/menus.en.toml index d8a1ad5a..d262c6df 100644 --- a/config/_default/menus/menus.en.toml +++ b/config/_default/menus/menus.en.toml @@ -88,10 +88,10 @@ url = "/storage-providers/get-started" [[storage-providers]] - name = "Configure" + name = "Setup" weight = 25 - identifier = "storage-providers-configure" - url = "/storage-providers/configure" + identifier = "storage-providers-setup" + url = "/storage-providers/setup" [[storage-providers]] name = "Operate" @@ -124,7 +124,6 @@ identifier = "tutorials-providers" url = "/tutorials/lotus-miner" - [[reference]] name = "API" weight = 10 @@ -144,6 +143,7 @@ # url = "/tutorials/store-and-retrieve" + [[social]] name = "GitHub" pre = "" diff --git a/content/en/kb/ImportData/index.md b/content/en/kb/ImportData/index.md index b9267e07..f2eec7c5 100644 --- a/content/en/kb/ImportData/index.md +++ b/content/en/kb/ImportData/index.md @@ -13,7 +13,7 @@ types: ["solution"] areas: ["function", "bidbot", "Lotus Node", "Markets Node"] --- -# Problem: +## Problem: Where does the `ImportData` function get executed? @@ -21,15 +21,15 @@ Where does the `ImportData` function get executed? > During normal operation bidbot listens, bids, downloads data, and then calls ImportData. https://github.com/textileio/bidbot/blob/v0.1.6/service/store/store.go#L615-L622 -The question is: How do you organize your API access/where bidbot runs? Does it expect the above to happen on the market node, or do you actual give bidbot miner-node credentials? Something else? +The question is: How do you organize your API access/where bidbot runs? Does it expect the above to happen on the market node, or do you actually give bidbot miner-node credentials? Something else? -# Environment: +## Environment: - Mainnet - Calibnet - Split markets node -# Resolution: +## Resolution: The `ImportData` function is always called/processed on the market node, regardless of any split configurations between a market node and the main miner-node. diff --git a/content/en/kb/add-swap/index.md b/content/en/kb/add-swap/index.md new file mode 100644 index 00000000..59306c00 --- /dev/null +++ b/content/en/kb/add-swap/index.md @@ -0,0 +1,32 @@ +--- +title: "Add swap on Linux" +description: "This is a guide for adding swap to a linux machine." +date: 2022-03-17T12:00:35+01:00 +lastmod: 2021-11-16T12:00:35+01:00 +draft: false +menu: + kb: + parent: "browse" +toc: false +pinned: false +types: ["article"] +areas: ["swap", "Linux"] +--- + +## Add swap on lotus miner or worker node: + +If you only have 128 GiB of RAM, you will need to make sure your system provides at least an extra 256 GiB of very fast swap (preferably NVMe SSD) or you will be unable to seal sectors: + +```shell +sudo fallocate -l 256G /swapfile +sudo chmod 600 /swapfile +sudo mkswap /swapfile +sudo swapon /swapfile +# show current swap spaces and take note of the current highest priority +swapon --show +# append the following line to /etc/fstab (ensure highest priority) and then reboot +# /swapfile swap swap pri=50 0 0 +sudo reboot +# check a 256GB swap file is automatically mounted and has the highest priority +swapon --show +``` diff --git a/content/en/kb/failed-to-create-datastore/index.md b/content/en/kb/failed-to-create-datastore/index.md index 8a389b14..6db3826c 100644 --- a/content/en/kb/failed-to-create-datastore/index.md +++ b/content/en/kb/failed-to-create-datastore/index.md @@ -13,6 +13,8 @@ types: ["solution"] areas: ["sealing", "Lotus Worker", "Lotus Miner"] --- +## Problem + The following error shows up in the worker's log. ```json diff --git a/content/en/kb/lotus-shed-not-installed/index.md b/content/en/kb/lotus-shed-not-installed/index.md index a224fd32..2dfc4ebe 100644 --- a/content/en/kb/lotus-shed-not-installed/index.md +++ b/content/en/kb/lotus-shed-not-installed/index.md @@ -1,6 +1,6 @@ --- -title: "lotus-shed is not installed by default" -description: "This is a solution for lotus-shed." +title: "How to install lotus-shed" +description: "This is a guide for installing lotus-shed." date: 2022-03-17T12:00:35+01:00 lastmod: 2021-11-16T12:00:35+01:00 draft: false @@ -9,19 +9,19 @@ menu: parent: "browse" toc: false pinned: false -types: ["solution"] +types: ["article"] areas: ["lotus-shed", "Linux", "Lotus Node"] --- -# Problem: +## Problem: When installing lotus for mainnet, lotus-shed is not installed by default. -# Environment: +## Environment: - Mainnet -# Resolution: +## Resolution: After lotus installs (completely) run `make install lotus-shed` diff --git a/content/en/kb/soft-fd-limit/index.md b/content/en/kb/soft-fd-limit/index.md index 4f2e9f37..37c3a804 100644 --- a/content/en/kb/soft-fd-limit/index.md +++ b/content/en/kb/soft-fd-limit/index.md @@ -13,7 +13,7 @@ types: ["solution"] areas: ["OS", "Linux", "Lotus Node"] --- -# Problem: +## Problem: An alert, similar to the following, shows up in lotus or lotus-miner. @@ -21,13 +21,13 @@ An alert, similar to the following, shows up in lotus or lotus-miner. Note that this error is an example from Ubuntu, but would be similar in other OS variants. -# Environment: +## Environment: * Mainnet * Calibnet * Devnet -# Resolution: +## Resolution: This will be host OS specific, but it should be similar on all OS types. Below is the example from Ubuntu. You will also have to reboot. ``` diff --git a/content/en/lotus/manage/troubleshooting.md b/content/en/lotus/manage/troubleshooting.md index 282ebc6c..a2c0d475 100644 --- a/content/en/lotus/manage/troubleshooting.md +++ b/content/en/lotus/manage/troubleshooting.md @@ -82,7 +82,7 @@ If you get a `signal killed` error, it could indcate that there was an error dur make: *** [Makefile:68: lotus] Error 1 ``` -Double check that your computer meets the [minimum hardware requirements]({{< relref "prerequisites#minimal-requirements" >}}) for Lotus. +Double check that your computer meets the [minimum hardware requirements]({{< relref "../../lotus/install/prerequisites#minimal-requirements" >}}) for Lotus. ## Go command not found diff --git a/content/en/storage-providers/advanced-configurations/logging.md b/content/en/storage-providers/advanced-configurations/logging.md new file mode 100644 index 00000000..dfe77f1a --- /dev/null +++ b/content/en/storage-providers/advanced-configurations/logging.md @@ -0,0 +1,83 @@ +--- +title: "Logging" +description: "This guide covers the Lotus Miner log configuration and logging usage." +lead: "This guide describes how to capture logs to a file and search through the file for important events." +draft: false +menu: + storage-providers: + parent: "storage-providers-advanced-configurations" +weight: 160 +toc: true +--- + +## Log file configuration + +The `lotus-miner` process generates Go logs and Rust logs. Both of these can be redirected to individual files. + +{{< alert icon="callout" >}} +This section is not applicable if you are running `lotus-miner` as a systemd service. +{{< /alert >}} + +### Redirect Go logs to a file + +By default, lotus-miner redirect all logs to the standard output if not running as a systemd service. To change this behavior, add the following variable to the `.bashrc` file and restart the Lotus miner process to start redirecting all logs to the file. + +```shell +export GOLOG_OUTPUT=FILE >> ~/.bashrc +export GOLOG_FILE="$HOME/miner.log" >> ~/.bashrc && source ~/.bashrc +``` + +### Redirect Rust logs to a standard output + +By default the `fil_logger` library used by `rust-fil-proof` doesn't log anything. You can change this by setting the RUST_LOG environment variable to another level. This will show log output on stderr which can be redirected to a file in the shell while launching the `lotus-miner` command. + +```shell +export RUST_LOG=info >> ~/.bashrc && source ~/.bashrc +``` + +The log-level can be chosen between 5 options: + +- trace +- debug +- info +- warn +- error + +## Change logging verbosity + +The verbosity of the `lotus` and `lotus-miner` logs can be changed without restarting the lotus. The following command can be used to list different subsystems within the `lotus-miner` process and change the verbosity of individual subsystem to get more/less detailed logs. + +```shell +lotus-miner log list +``` + +To change the verbosity, please run: + +```shell +lotus-miner log set-level --system chain debug +``` + +The log-level can be chosen between 4 options: + +- debug +- info +- warn +- error + +You can specify multiple subsystems to change the log level of multiple subsystems at once. + +```shell +lotus-miner log set-level --system chain --system chainxchg debug +``` + +## Searching through logs + +1. To look for logs related to mining a block, you can check with following commands. + ```shell + cat /path/to/log | grep "mined" + ``` + +2. To look for logs related to winning a block, you can check with following commands. + ```shell + cat /path/to/log | grep "isEligible" + ``` diff --git a/content/en/storage-providers/advanced-configurations/market.md b/content/en/storage-providers/advanced-configurations/market.md new file mode 100644 index 00000000..2dee5c5d --- /dev/null +++ b/content/en/storage-providers/advanced-configurations/market.md @@ -0,0 +1,118 @@ +--- +title: "Market" +description: "Lotus has a lot of advanced configurations you can tune to optimize your storage provider setup. This guide explains the advanced configuration options for lotus market" +lead: "Lotus has a lot of advanced configurations you can tune to optimize your storage provider setup. This guide explains the advanced configuration options for lotus market" +draft: false +menu: + storage-providers: + parent: "storage-providers-advanced-configurations" +weight: 120 +toc: true +--- + +## Dealmaking section + +This section controls parameters for making storage and retrieval deals: + +```toml +[Dealmaking] + # When enabled, the miner can accept online deals + ConsiderOnlineStorageDeals = true + # When enabled, the miner can accept offline deals + ConsiderOfflineStorageDeals = true + # When enabled, the miner can accept retrieval deals + ConsiderOnlineRetrievalDeals = true + # When enabled, the miner can accept offline retrieval deals + ConsiderOfflineRetrievalDeals = true + # When enabled, the miner can accept verified deals + ConsiderVerifiedStorageDeals = true + # When enabled, the miner can accept unverified deals + ConsiderUnverifiedStorageDeals = true + # A list made of Data CIDs to reject when making deals + PieceCidBlocklist = [] + # Maximum expected amount of time getting the deal into a sealed sector will take + # This includes the time the deal will need to get transferred and published + # before being assigned to a sector + # for more info, see below. + ExpectedSealDuration = "24h0m0s" + # When a deal is ready to publish, the amount of time to wait for more + # deals to be ready to publish before publishing them all as a batch + PublishMsgPeriod = "1h0m0s" + # The maximum number of deals to include in a single publish deals message + MaxDealsPerPublishMsg = 8 + + # A command used for fine-grained evaluation of storage deals (see below) + Filter = "/absolute/path/to/storage_filter_program" + + # A command used for fine-grained evaluation of retrieval deals (see below) + RetrievalFilter = "/absolute/path/to/retrieval_filter_program" +``` + +`ExpectedSealDuration` is an estimate of how long sealing will take and is used to reject deals whose start epoch might be earlier than the expected completion of sealing. It can be estimated by [benchmarking]({{< relref "benchmarks" >}}) or by [pledging a sector]({{< relref "sector-pledging" >}}). + +{{< alert icon="warning" >}} +The final value of `ExpectedSealDuration` should equal `(TIME_TO_SEAL_A_SECTOR + WaitDealsDelay) * 1.5`. This equation ensures that the miner does not commit to having the sector sealed too soon. +{{< /alert >}} + +`StartEpochSealingBuffer` allows `lotus-miner` to seal a sector before a certain epoch. For example: if the current epoch is 1000 and a deal within a sector must start on epoch 1500, then `lotus-miner` must wait until the current epoch is 1500 before it can start sealing that sector. However, if `lotus-miner` sets `StartEpochSealingBuffer` to 500, the `lotus-miner` can start sealing the sector at epoch 1000. + +If there are multiple deals in a sector, the deal with a start time closest to the current epoch is what `StartEpochSealingBuffer` will be based off. So, if the sector in our example has three deals that start on epoch 1000, 1200, and 1400, then we `lotus-miner` will start sealing the sector at epoch 500. + +### Disabling new sector for deal + +If `MakeNewSectorForDeals` is set to `true` then `lotus-miner` will create new sectors for incoming deals. This option can set to `false` to ensure that all new deals are sealed as snap-deals into CC sectors. This can help reduce the sealing time for the new deals as long as CC sectors are ready for the snap-deals. + +### Make new CC sector available for snap-deal + +`MakeCCSectorsAvailable` makes all the new CC sectors available to be upgraded with snap-deals. When this boolean is set to `true`, all pledged "CC" sectors from that point onwards will be converted to "Available" state after sealing. This enables sealing the incoming storage deals more quickly into these "Available" sectors compared to creating a new sector for the deals. + +### Publishing several deals in one message + +The `PublishStorageDeals` message can publish multiple deals in a single message. +When a deal is ready to be published, Lotus will wait up to `PublishMsgPeriod` +for other deals to be ready before sending the `PublishStorageDeals` message. + +However, once `MaxDealsPerPublishMsg` is ready, Lotus will immediately publish all the deals. + +For example, if `PublishMsgPeriod` is 1 hour: + +- At 1:00 pm, deal 1 is ready to publish. Lotus will wait until 2:00 pm for other deals to be ready before sending `PublishStorageDeals`. +- At 1:30 pm, Deal 2 is ready to publish +- At 1:45 pm, Deal 3 is ready to publish +- At 2:00pm, lotus publishes Deals 1, 2, and 3 in a single `PublishStorageDeals` message. + +If `MaxDealsPerPublishMsg` is 2, then in the above example, when deal 2 is ready to be published at 1:30, Lotus would immediately publish Deals 1 & 2 in a single `PublishStorageDeals` message. Deal 3 would be published in a subsequent `PublishStorageDeals` message. + +{{< alert icon="👉" >}} +If any of the deals in the `PublishStorageDeals` fails validation upon execution, or if the start epoch has passed, all deals will fail to be published. +{{< /alert >}} + +## Using filters for fine-grained storage and retrieval deal acceptance + +Your use case might demand very precise and dynamic control over a combination of deal parameters. + +Lotus provides two IPC hooks allowing you to name a command to execute for every deal before the miner accepts it: + +- `Filter` for storage deals. +- `RetrievalFilter` for retrieval deals. + +The executed command receives a JSON representation of the deal parameters on standard input, and upon completion, its exit code is interpreted as: + +- `0`: success, proceed with the deal. +- `non-0`: failure, reject the deal. + +The most trivial filter rejecting any retrieval deal would be something like: +`RetrievalFilter = "/bin/false"`. `/bin/false` is binary that immediately exits with a code of `1`. + +[This Perl script](https://gist.github.com/ribasushi/53b7383aeb6e6f9b030210f4d64351d5/9bd6e898f94d20b50e7c7586dc8b8f3a45dab07c#file-dealfilter-pl) lets the miner deny specific clients and only accept deals that are set to start relatively soon. + +You can also use a third party content policy framework like `bitscreen` by Murmuration Labs: + +```shell +# grab filter program +go get -u -v github.com/Murmuration-Labs/bitscreen + +# add it to both filters +Filter = "/path/to/go/bin/bitscreen" +RetrievalFilter = "/path/to/go/bin/bitscreen" +``` diff --git a/content/en/storage-providers/advanced-configurations/sealing.md b/content/en/storage-providers/advanced-configurations/sealing.md new file mode 100644 index 00000000..866ca82d --- /dev/null +++ b/content/en/storage-providers/advanced-configurations/sealing.md @@ -0,0 +1,251 @@ +--- +title: "Sealing" +description: "Lotus has a lot of advanced configurations you can tune to optimize your storage provider setup. This guide explains the advanced configuration options for lotus market" +lead: "This guide explains the advanced configuration options available for optimizing the sealing pipeline on a lotus-miner" +draft: false +menu: + storage-providers: + parent: "storage-providers-advanced-configurations" +weight: 120 +toc: true +--- + +## Sealing section + +This section controls some of the behavior around sector sealing: + +```toml +[Sealing] + # Upper bound on how many sectors can be waiting for more deals to be packed in it before it begins sealing at any given time. + # If the miner is accepting multiple deals in parallel, up to MaxWaitDealsSectors of new sectors will be created. + # If more than MaxWaitDealsSectors deals are accepted in parallel, only MaxWaitDealsSectors deals will be processed in parallel + # Note that setting this number too high in relation to deal ingestion rate may result in poor sector packing efficiency + MaxWaitDealsSectors = 2 + # Upper bound on how many sectors can be sealing at the same time when creating new CC sectors (0 = unlimited) + MaxSealingSectors = 0 + # Upper bound on how many sectors can be sealing at the same time when creating new sectors with deals (0 = unlimited) + MaxSealingSectorsForDeals = 0 + # CommittedCapacitySectorLifetime is the duration a Committed Capacity (CC) sector will + # live before it must be extended or converted into sector containing deals before it is + # terminated. Value must be between 180-540 days inclusive + # + # type: Duration + CommittedCapacitySectorLifetime = "12960h0m0s" + + # Period of time that a newly created sector will wait for more deals to be packed in to before it starts to seal. + # Sectors which are fully filled will start sealing immediately + WaitDealsDelay = "6h0m0s" + # Whether to keep unsealed copies of deal data regardless of whether the client requested that. This lets the miner + # avoid the relatively high cost of unsealing the data later, at the cost of more storage space + AlwaysKeepUnsealedCopy = true + # Run sector finalization before submitting sector proof to the chain + FinalizeEarly = false + # Whether to use available miner balance for sector collateral instead of sending it with each message + CollateralFromMinerBalance = false + # Minimum available balance to keep in the miner actor before sending it with messages + AvailableBalanceBuffer = 0 + # Don't send collateral with messages even if there is no available balance in the miner actor + DisableCollateralFallback = false + # enable / disable precommit batching (takes effect after nv13) + BatchPreCommits = true + # maximum precommit batch size up to 256 sectors - batches will be sent immediately above this size + MaxPreCommitBatch = 256 + # how long to wait before submitting a batch after crossing the minimum batch size + PreCommitBatchWait = "24h0m0s" + # time buffer for forceful batch submission before sectors/deal in batch would start expiring + PreCommitBatchSlack = "3h0m0s" + + # enable / disable commit aggregation (takes effect after nv13) + AggregateCommits = true + # minimum batched commit size, no less than 4 + MinCommitBatch = 4 + # maximum batched commit size up to 819 sectors - batches will be sent immediately above this size + MaxCommitBatch = 819 + # how long to wait before submitting a batch after crossing the minimum batch size + CommitBatchWait = "24h0m0s" + # time buffer for forceful batch submission before sectors/deals in batch would start expiring + CommitBatchSlack = "1h0m0s" + + # network BaseFee below which to stop doing commit aggregation, instead submitting proofs to the chain individually + AggregateAboveBaseFee = 0.00000000015 #0.15nano + + + TerminateBatchMax = 100 + TerminateBatchMin = 1 + TerminateBatchWait = "5m0s" +``` + +### PreCommitSectorsBatch + +`PreCommitSectorsBatch` introduced by [FIP-0008 ](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0008.md) supports a miner to pre-commit a number of sectors at once. + +In lotus v1.10.0 and up, if `BatchPreCommit` is set to false, pre-commitments will be sent to the chain via `PreCommitSector` messages once they are ready. If `BatchPreCommit` is set to true, lotus will batch pre-commitments until any of `MaxPreCommitBatch`, `PreCommitBatchWait` or `PreCommitBatchSlack` is hit: +- `MaxPreCommitBatch` is the maximum amount of sectors' pre-commitments to batch in one `PreCommitSectorsBatch` message. According to FIP-0008, this values is up to 256. +- `PreCommitBatchWait` is how long to wait before submitting the current batch. Note: the ticket of pre-commitment has an expiration of approximately **31.5 hours**, one sector's pre-commit ticket expires **WILL** cause the whole message to fail. Therefore, **we recommend miners to set this value lower than 30 hours.** +- `PreCommitBatchSlack` is the time buffer to forcefully submit the current batch before any of the sector's pre-commit ticket or a deal will expire. For example, if this value is set to 1 hour, which is 120 epochs, then a `PreCommitSectorsBatch` message will be submitted for the existing batch 120 epochs before the earliest epoch among precommits' tickets and deal's start epochs in this batch. **We recommend you to set a longer slack to prevent message failures due to expirations.** + +{{< alert icon="👉" >}} +The current batch will be sent if any of `MaxPreCommitBatch`, `PreCommitBatchWait` or `PreCommitBatchSlack` is hit. +{{< /alert >}} + +To check the list of the sectors pre-commitments that are in the batching queue, run: + +```shell +./lotus-miner sectors batching precommit +``` + +This will output the sector IDs: + +```shell +14 +15 +16 +``` + +To ignore the configuration and force push the current batch, run: + +```shell +./lotus-miner sectors batching precommit --publish-now=true +``` + +Then in the output, the message CID of the `PreCommitSectorsBatch` message and the sector number of the sectors' pre-commitments that are being submitted is listed: + +```shell +Batch 0: + Message: bafy2bzacecgihnlvbsqu7yksco3vs5tzk3ublbcnkedlofr6nhbq55k5ye3ci + Sectors: + 14 OK + 15 OK + 16 OK +``` + +### ProveCommitAggregate + +`ProveCommitAggregate` introduced by [FIP-0013](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0013.md) supports a miner to prove-commit a number of sectors at ones. + +In Lotus v1.10.0 and up, if `AggregateCommits` is set to false, prove-commitments will be sent to the chain via `ProveCommitSector` messages once they are ready. If `AggregateCommits` is set to true, lotus will aggregate and batch pre-commitments until any of `MaxCommitBatch`, `CommitBatchWait` or `CommitBatchSlack` is hit: +- `MaxCommitBatch` is the maximum amount of sectors' prove-commitments to batch in one `ProveCommitAggregate` message. According to FIP-0013, this value is up to 819. +- `CommitBatchWait` is how long to wait before submitting the current batch **after** crossing `MinCommitBatch`. Note: a prove-commitment must be submitted **within 30 days** after the pre-commit has landed on-chain. It is recommended to set this value lower than 30 days to prevent collateral loss. +- `CommitBatchSlack` is the time buffer to forcefully submit the current batch before any of the sector's pre-commitment or a deal will expire. For example, if this value is set to 1 hour, which is 120 epochs, then a `ProveCommitAggregate` message will be submitted for the existing batch 120 epochs before the earliest epoch among precommits' expirations and deals' start epochs in this batch. **We recommend you to set a longer slack to prevent message failures due to deal expirations or loss of collateral** +- `AggregateAboveBaseFee` is the network base fee to start aggregating proofs. When the network base fee is lower than this value, the prove commits will be submitted individually via `ProveCommitSector`. **According to the [Batch Incentive Alignment](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0013.md#batch-incentive-alignment) introduced in FIP-0013, we recommend you to set this value to 0.15 nanoFIL to avoid unexpected aggregation fee in burn.** + +`MinCommitBatch` is the minimum amount of sectors' prove-commitment to be batched in one `ProveCommitAggregate` message. According to FIP-0013, this value cannot be less than 4, which is the cross-over point where prove-commit aggregation wins out on single prove-commit gas costs. If any of `MaxCommitBatch`, `CommitBatchWait` or `CommitBatchSlack` is hit by the amount of prove-commit is the batching queue is less than `MinCommitBatch`, then prove-commitments in this batch will be proceeded individually via `ProveCommitSector`. + +{{< alert icon="👉" >}} +Aggregated proofs will incur a discounted Gas Charge, so overall, it will be less gas usage than the same number of proofs on-chain, but a minimum fee will apply. It is _cheaper per proof_ to aggregate more proofs into a single aggregate message, meaning aggregating 1000 proofs is more beneficial than aggregating 10 sectors. So if a miner wants to onboard more storage, it is recommended to aggregate more proofs into a single message. +{{< /alert >}} + +To check the list of the sectors prove-commitments that are in the batching queue, run: + +```shell +./lotus-miner sectors batching commit +``` + +This will output something like: + +```shell +10 +11 +12 +13 +14 +15 +16 +17 +``` + +To ignore the configuration and force push the current batch, run: + +```shell +./lotus-miner sectors batching commit --publish-now=true +``` + +Then in the output, the message CID of the `ProveCommitAggregate` message and the sector number of the sectors' prove-commitments that are being submitted is listed: + +```shell +Batch 0: + Message: bafy2bzacedtmykgf5g4evdvapacpmo4l32ewu5l7yxqkzjh3h6fhev7v7qoys + Sectors: + 15 OK + 17 OK + 12 OK + 10 OK + 11 OK + 13 OK + 16 OK + 14 OK +``` + +If the sectors in the queue are less than `MinCommitBatch`, then individual `ProveCommitSector` messages will be sent for each sector: + +```shell +Batch 0: + Message: bafy2bzacedpwysxdsg2ft3hfbwn6ayyaanivfwkx4inav3zm34hwmmwgsljkk + Sectors: + 18 OK +Batch 1: + Message: bafy2bzacedrx7l34ckaue7hm2ubousl3djuigyu2xw4xzywgkhttxecsm5ba2 + Sectors: + 19 OK +``` + +### CommittedCapacitySectorLifetime + +The available units are: + +```shell +"ms": int64(Millisecond), + "s": int64(Second), + "m": int64(Minute), + "h": int64(Hour), +``` + +For example, if you want to set the sector lifecycle to 180 days, you can multiply 180 days by 24 hours per day to get 4320 hours and set this value to `"4320h0m0s"`. + +## Storage section + +The storage sector controls whether the miner can perform certain sealing actions. Depending on the setup and the use of additional [seal workers]({{< relref "seal-workers" >}}), you may want to modify some of the options. + +```toml +[Storage] + # Upper bound on how many sectors can be fetched in parallel by the storage system at a time + ParallelFetchLimit = 10 + # Sealing steps that the miner can perform itself. Sometimes we have a dedicated seal worker to do them and do not want the miner to commit any resources for this. + AllowAddPiece = true + AllowPreCommit1 = true + AllowPreCommit2 = true + AllowCommit = true + AllowUnseal = true +``` + +## Fees section + +The fees section allows to set limits to the gas consumption for the different messages that are submitted to the chain by the miner: + +```toml +[Fees] + # Maximum fees to pay + MaxPreCommitGasFee = "0.025 FIL" + MaxCommitGasFee = "0.05 FIL" + MaxTerminateGasFee = "0.5 FIL" + # This is a high-value operation, so the default fee is higher. + MaxWindowPoStGasFee = "5 FIL" + MaxPublishDealsFee = "0.05 FIL" + MaxMarketBalanceAddFee = "0.007 FIL" + [Fees.MaxPreCommitBatchGasFee] + Base = "0 FIL" + PerSector = "0.02 FIL" + [Fees.MaxCommitBatchGasFee] + Base = "0 FIL" + PerSector = "0.03 FIL" + +``` + +Depending on the network congestion, the base fee for a message may grow or decrease. Your gas limits will have to be larger than the base fee for the messages to be included. A very large max fee can, however, result in the quick burning of funds when the base fee is very high, as the miner automatically submits messages during normal operation, so be careful about this. It is also necessary to have more funds available than any max fee set, even if the actual fee will be far less than the max fee set. + +Set the maximum cost you are willing to pay for onboarding **per** sector in `MaxPreCommitBatchGasFee.PerSector`/`MaxCommitBatchGasFee.PerSector` to avoid unexpected high costs. + +{{< alert icon="👉" >}} +The current `MaxCommitBatchGasFee.PerSector` is enough to aggregate proofs for 6 sectors. Adjust this respectively according to your operation. **If the value is too low, the message may wait in the mempool for a long while. If you don't have enough funds, the message will not be sent.** +{{< /alert >}} + diff --git a/content/en/storage-providers/configure/split-markets-miners/index.md b/content/en/storage-providers/advanced-configurations/split-markets-miners/index.md similarity index 99% rename from content/en/storage-providers/configure/split-markets-miners/index.md rename to content/en/storage-providers/advanced-configurations/split-markets-miners/index.md index 776f1c79..3f0ac1f1 100644 --- a/content/en/storage-providers/configure/split-markets-miners/index.md +++ b/content/en/storage-providers/advanced-configurations/split-markets-miners/index.md @@ -5,11 +5,12 @@ lead: "Lotus performs mining operations, such as sealing files into sectors, cal draft: false menu: storage-providers: - parent: "storage-providers-configure" + parent: "storage-providers-advanced-configurations" identifier: "storage-providers-split-markets" aliases: - /docs/storage-providers/split-markets-miners/ -weight: 140 + - /storage-providers/configure/split-markets-miners/ +weight: 130 toc: true --- diff --git a/content/en/storage-providers/configure/split-markets-miners/miner-markets-segregation-v4.png b/content/en/storage-providers/advanced-configurations/split-markets-miners/miner-markets-segregation-v4.png similarity index 100% rename from content/en/storage-providers/configure/split-markets-miners/miner-markets-segregation-v4.png rename to content/en/storage-providers/advanced-configurations/split-markets-miners/miner-markets-segregation-v4.png diff --git a/content/en/storage-providers/configure/lotus-miner-log.md b/content/en/storage-providers/configure/lotus-miner-log.md deleted file mode 100644 index 48a16428..00000000 --- a/content/en/storage-providers/configure/lotus-miner-log.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "Lotus Miner Logging" -identifier: "storage-provider-configuration" -description: "This guide covers the Lotus Miner log configuration and logging usage." -draft: true -menu: - storage-providers: - parent: "lotus-miner-configure" -weight: 160 -toc: true ---- - -TODO: -Add how logging happens in lotus-miner. -How to capture all output to proper logs files. Get details from lotus engineering on this. -How to rotate logs. -How to serach logs for important events. diff --git a/content/en/storage-providers/configure/setup.md b/content/en/storage-providers/configure/setup.md deleted file mode 100644 index 56794262..00000000 --- a/content/en/storage-providers/configure/setup.md +++ /dev/null @@ -1,233 +0,0 @@ ---- -title: "Setup" -description: "This guide describes the necessary steps to configure a Lotus miner for production." -lead: "This guide describes the necessary steps to configure a Lotus miner for production." -draft: false -menu: - storage-providers: - parent: "storage-providers-configure" - identifier: "storage-providers-configure-setup" -aliases: - - /docs/storage-providers/setup/ -weight: 100 -toc: true ---- - -Mining will only work if you fully cover the [minimal hardware requirements]({{< relref "hardware-requirements" >}}) for the network in which you will mine. As the mining process is very demanding for the machines on several aspects and relies on precise configuration, we strongly recommend Linux systems administration experience before embarking. - -## Pre-requisites - -Before attempting to follow this guide: - -- Make sure you meet the [minimal hardware requirements]({{< relref "hardware-requirements" >}}). -- Make sure you have followed the instructions to [install the Lotus suite]({{< relref "prerequisites" >}}) and make sure you have built Lotus with "Native Filecoin FFI". Once the installation is complete, `lotus`, `lotus-miner` and `lotus-worker` will be installed. -- Make sure your Lotus Node is running as the miner will communicate with it and cannot work otherwise. -- If you are in China, read the [tips for running in China]({{< relref "prerequisites#node-in-china" >}}) page first. - -{{< alert icon="callout" >}} -Be warned: if you decide to skip any of the sections below, things will not work! Read and tread carefully. -{{< /alert >}} - -## Before starting the miner - -Follow these sections through _before_ attempting to start the miner. Running `lotus-miner` prematurely will cause errors. - -### Install extra dependencies - -If you are running an Nvidia GPU, install `nvidia-opencl-icd`. Most Linux distributions contain this package in their package manager: - -```shell -sudo apt update -y && sudo apt install -y nvidia-opencl-icd -y -``` - -### Performance tweaks - -It is recommended to set the following environment variables in your environment so that they are defined **every time any of the Lotus applications is launched** (meaning, when the daemons are started): - -```sh -# See https://github.com/filecoin-project/bellman -export BELLMAN_CPU_UTILIZATION=0.875 -``` - -The `BELLMAN_CPU_UTILIZATION` is an optional variable to designate a proportion of the multi-exponentiation calculation to be moved to a CPU in parallel to the GPU. This is an effort to keep all the hardware occupied. The interval must be a number between `0` and `1`. The value `0.875` is a good starting point, but you should experiment with it if you want an optimal setting. Different hardware setups will result in different values being optimal. Omitting this environment variable might also be optimal. - -```sh -# See https://github.com/filecoin-project/rust-fil-proofs/ -export FIL_PROOFS_MAXIMIZE_CACHING=1 # More speed at RAM cost (1x sector-size of RAM - 32 GB). -export FIL_PROOFS_USE_GPU_COLUMN_BUILDER=1 # precommit2 GPU acceleration -export FIL_PROOFS_USE_GPU_TREE_BUILDER=1 - -# The following increases speed of PreCommit1 at the cost of using a full -# CPU Core-Complex rather than a single core. Should be used with CPU affinities set! -# See https://github.com/filecoin-project/rust-fil-proofs/ and the seal workers guide. -export FIL_PROOFS_USE_MULTICORE_SDR=1 -``` - -### Running the miner on a different machine as the Lotus Node - -If you opt to run a miner on a different machine as the Lotus Node, set: - -```sh -export FULLNODE_API_INFO=:/ip4//tcp//http -``` - -and **make sure the `ListenAddress` has [remote access enabled]({{< relref "../../developers/api-access#enable-remote-api-access" >}})**. Instructions on how to obtain a token are [available here]({{< relref "api-access#obtaining-tokens" >}}). - -Similarly, `lotus-miner` (as a client application to the Lotus Miner daemon), can talk to a remote miner by setting: - -```sh -export MINER_API_INFO="TOKEN:/ip4//tcp//http" -export MARKETS_API_INFO="TOKEN:/ip4//tcp//http" -``` - -### Adding the necessary swap - -If you have only 128 GiB of RAM, you will need to make sure your system provides at least an extra 256 GiB of very fast swap (preferably NVMe SSD) or you will be unable to seal sectors: - -```sh -sudo fallocate -l 256G /swapfile -sudo chmod 600 /swapfile -sudo mkswap /swapfile -sudo swapon /swapfile -# show current swap spaces and take note of the current highest priority -swapon --show -# append the following line to /etc/fstab (ensure highest priority) and then reboot -# /swapfile swap swap pri=50 0 0 -sudo reboot -# check a 256GB swap file is automatically mounted and has the highest priority -swapon --show -``` - -### Creating wallets for the miner - -You will need at least a BLS wallet (`f3...` for mainnet) for mining. We recommend using [separate owner and worker addresses]({{< relref "addresses" >}}): - -```sh -# A new BLS address to use as owner address: -lotus wallet new bls -f3... - -# A new BLS address to use as worker address: -lotus wallet new bls -f3... -``` - -{{< alert icon="callout" >}} -Next make sure to [send some funds]({{< relref "manage-fil" >}}) to the **worker address** so that the miner setup can be completed. The amount you should initialize with varies with gas fees, but 0.1 FIL is generally a safe amount. The sender doesn't have to be any particular address and can be specified using the `from` flag. If `from` is unspecified, the sender will default to the `owner` address, in which case the `onwer` must have the 0.1 FIL. If the `owner` is also unspecified, the wallet's default address is used as the owner and that address must have the 0.1 FIL. -{{< /alert >}} - -For additional information about the different wallets that a miner can use and how to configure them, read the [miner addresses guide]({{< relref "addresses" >}}). - -{{< alert icon="tip" >}} -Safely [backup your wallets]({{< relref "manage-fil#exporting-and-importing-addresses" >}})! -{{< /alert >}} - -### Downloading parameters - -For the miner to start, it will need to read and verify the Filecoin proof parameters. These can be downloaded in advance (recommended), or otherwise the init process will. Proof parameters consist of several files, which in the case of 32 GiB sectors, total **over 100 GiB**. - -We recommend setting a custom location to store parameters and proofs parent cache -created during the first run- with: - -```sh -export FIL_PROOFS_PARAMETER_CACHE=/path/to/folder/in/fast/disk -export FIL_PROOFS_PARENT_CACHE=/path/to/folder/in/fast/disk2 -``` - -Parameters are read on every (re)start, so using disks with very fast access, like NVMe drives, will speed up miners and workers (re)boots. When the above variables are not set, things will end up in `/var/tmp/` by default, which **often lacks enough space**. - -To download the parameters do: - -```sh -# Use sectors supported by the Filecoin network that the miner will join and use. -# lotus-miner fetch-params -lotus-miner fetch-params 32GiB -lotus-miner fetch-params 64GiB -``` - -You can verify sectors sizes for a network in the [network dashboard](https://network.filecoin.io). The `FIL_PROOFS_*_CACHE` variables should stay defined not only for download, but also when starting the Lotus miner (or workers). - -## Checklist before launch - -To summarize, make sure that: - -- The _worker address_ has some funds so that the miner can be initialized. -- The following environment variables have been defined and will be available for any Lotus miner runs: - - ``` - export LOTUS_MINER_PATH=/path/to/miner/config/storage - export LOTUS_PATH=/path/to/lotus/node/folder # When using a local node. - export BELLMAN_CPU_UTILIZATION=0.875 # Optimal value depends on your exact hardware. - export FIL_PROOFS_MAXIMIZE_CACHING=1 - export FIL_PROOFS_USE_GPU_COLUMN_BUILDER=1 # When having GPU. - export FIL_PROOFS_USE_GPU_TREE_BUILDER=1 # When having GPU. - export FIL_PROOFS_PARAMETER_CACHE=/fast/disk/folder # > 100GiB! - export FIL_PROOFS_PARENT_CACHE=/fast/disk/folder2 # > 50GiB! - export TMPDIR=/fast/disk/folder3 # Used when sealing. - ``` - -- Parameters have been prefetched to the cache folders specified above. -- The system has enough swap and it is active. - -## Miner initialization - -Before starting your miner for the first time run: - -```sh -lotus-miner init --owner=
--worker=
--no-local-storage -``` - -- The `--no-local-storage` flag is used so that we can later configure [specific locations for storage]({{< relref "custom-storage-layout" >}}). This is optional but recommended. -- The Lotus Miner configuration folder is created at `~/.lotusminer/` or `$LOTUS_MINER_PATH` if set. -- The difference between _owner_ and _worker_ addresses is explained in the [miner addresses guide]({{< relref "addresses" >}}). As mentioned above, we recommend using two separate addresses. If the `--worker` flag is not provided, the owner address will be used. _Control addresses_ can be added later when the miner is running. - -## Connectivity to the miner - -Before you start your miner, it is important to configure it so that it is reachable from any peer in the Filecoin network. For this, you will need a stable public IP and edit your `~/.lotusminer/config.toml` as follows: - -```toml -... -[Libp2p] - ListenAddresses = ["/ip4/0.0.0.0/tcp/24001"] # choose a fixed port - AnnounceAddresses = ["/ip4//tcp/24001"] # important! -... -``` - -Once you start your miner, [make sure you can connect to its public IP/port]({{< relref "connectivity" >}}). - -## Starting the miner - -You are now ready to start your Lotus miner: - -```sh -lotus-miner run -``` - -or if you are using the systemd service file: - -```sh -systemctl start lotus-miner -``` - -{{< alert icon="warning" >}} -**Do not proceed** from here until you have verified that your miner not only is running, but also [reachable on its public IP address]({{< relref "connectivity" >}}). -{{< /alert >}} - -## Publishing the miner addresses - -Once the miner is up and running, publish your miner address (which you configured above) on the chain so that other nodes can talk to it directly and make deals: - -```sh -lotus-miner actor set-addrs /ip4//tcp/24001 -``` - -## Next steps - -Your miner should now be preliminarily set up and running, but **there are still a few more recommended tasks** to be ready for prime-time: - -- Set up your [custom storage layout]({{< relref "custom-storage-layout" >}}) (required if you used `--no-local-storage`). -- Edit the miner [configuration settings]({{< relref "configuration" >}}) to fit your requirements. -- Learn what is a right moment to [shut down/restart your miner]({{< relref "lifecycle" >}}) -- Update `ExpectedSealDuration` with the time it takes your miner to seal a sector: discover it by [running a benchmark]({{< relref "benchmarks" >}}) or by [pledging a sector]({{< relref "sector-pledging" >}}) and noting down the time. -- Configure additional [seal workers]({{< relref "seal-workers" >}}) to increase the miner's capacity to seal sectors. -- Configure a [separate address for WindowPost messages]({{< relref "addresses" >}}). -- Consider [splitting markets and miners processes]({{< relref "split-markets-miners" >}}) for increased stability. diff --git a/content/en/storage-providers/get-started/overview/index.md b/content/en/storage-providers/get-started/overview/index.md index bde14f47..8e442665 100644 --- a/content/en/storage-providers/get-started/overview/index.md +++ b/content/en/storage-providers/get-started/overview/index.md @@ -23,9 +23,9 @@ Lotus Mining for _mainnet_ has stringent minimal **[hardware requirements]({{< r The following guides are essential starting points for those willing to launch a Lotus miner: -- The miner installation is covered in the [Installation guide]({{< relref "prerequisites" >}}). Once the installation is complete, the Lotus node, Lotus miner, and Lotus worker applications should all be installed. +- The miner installation is covered in the [Installation guide]({{< relref "../../../lotus/install/prerequisites" >}}). Once the installation is complete, the Lotus node, Lotus miner, and Lotus worker applications should all be installed. -- The [Miner setup]({{< relref "setup" >}}) covers all the details to configure your miner to achieve the maximum performance and avoid common pitfalls. +- The [Miner setup]({{< relref "initialize" >}}) covers all the details to configure your miner to achieve the maximum performance and avoid common pitfalls. - The [Configuration reference]({{< relref "configuration" >}}) explains what the different miner configuration options mean. - The [Seal workers]({{< relref "seal-workers" >}}) guide covers how to run additional seal workers co-located or not with the Lotus Miner. diff --git a/content/en/storage-providers/operate/connectivity.md b/content/en/storage-providers/operate/connectivity.md index 9266eda2..8f92fa7a 100644 --- a/content/en/storage-providers/operate/connectivity.md +++ b/content/en/storage-providers/operate/connectivity.md @@ -13,7 +13,7 @@ weight: 130 toc: true --- -Filecoin miners, like participants in all peer-to-peer protocols, require a steady and quality pool of peers to communicate with in order to perform their various functions. This complements the [connectivity section]({{< relref "setup#connectivity-to-the-miner" >}}) in the setup instructions and the [seal workers]({{< relref "seal-workers" >}}) guide. +Filecoin miners, like participants in all peer-to-peer protocols, require a steady and quality pool of peers to communicate with in order to perform their various functions. This complements the [connectivity section]({{< relref "initialize#connectivity-to-the-miner" >}}) in the setup instructions and the [seal workers]({{< relref "seal-workers" >}}) guide. ## Finding your public IP address diff --git a/content/en/storage-providers/configure/custom-storage-layout.md b/content/en/storage-providers/operate/custom-storage-layout.md similarity index 85% rename from content/en/storage-providers/configure/custom-storage-layout.md rename to content/en/storage-providers/operate/custom-storage-layout.md index 2fdd32fc..ac470861 100644 --- a/content/en/storage-providers/configure/custom-storage-layout.md +++ b/content/en/storage-providers/operate/custom-storage-layout.md @@ -5,7 +5,7 @@ lead: "This guide describes how to specify custom storage locations for the Lotu draft: false menu: storage-providers: - parent: "storage-providers-configure" + parent: "storage-providers-operate" identifier: "storage-providers-configure-custom-storage-layout" aliases: - /docs/storage-providers/custom-storage-layout/ @@ -13,7 +13,7 @@ weight: 120 toc: true --- -If you used the `--no-local-storage` flag during the [miner initialization]({{< relref "setup#miner-initialization" >}}), you should specify the disk locations for sealing (fast SSD recommended) and long-term storage. +If you used the `--no-local-storage` flag during the [miner initialization]({{< relref "../setup/initialize#miner-initialization" >}}), you should specify the disk locations for sealing (fast SSD recommended) and long-term storage. The Lotus Miner keeps track of defined storage locations in in `~/.lotusminer/storage.json` (or `$LOTUS_MINER_PATH/storage.json`) and uses `~/.lotusminer` path as default. @@ -45,6 +45,6 @@ lotus-miner storage list ## Updating locations -To move data from one location to another, follow the instructions in the [Miner lifecycle guide]({{< relref "lifecycle#changing-storage-locations" >}}). +To move data from one location to another, follow the instructions in the [Miner maintenance guide]({{< relref "maintenance#changing-storage-locations" >}}). To fully remove one location, edit the `storage.json` manually and re-start your miner. diff --git a/content/en/storage-providers/configure/dagstore.md b/content/en/storage-providers/operate/dagstore.md similarity index 99% rename from content/en/storage-providers/configure/dagstore.md rename to content/en/storage-providers/operate/dagstore.md index 13a587cb..1aa3fa86 100644 --- a/content/en/storage-providers/configure/dagstore.md +++ b/content/en/storage-providers/operate/dagstore.md @@ -5,10 +5,11 @@ lead: "The dagstore is a sharded store to hold large IPLD graphs efficiently, pa draft: false menu: storage-providers: - parent: "storage-providers-configure" + parent: "storage-providers-operate" identifier: "storage-providers-configure-dagstore" aliases: - /docs/storage-providers/dagstore/ + - /storage-providers/configure/dagstore/ weight: 160 toc: true --- diff --git a/content/en/storage-providers/configure/lifecycle.md b/content/en/storage-providers/operate/maintenance.md similarity index 98% rename from content/en/storage-providers/configure/lifecycle.md rename to content/en/storage-providers/operate/maintenance.md index cb540b3e..11ad49c4 100644 --- a/content/en/storage-providers/configure/lifecycle.md +++ b/content/en/storage-providers/operate/maintenance.md @@ -1,14 +1,15 @@ --- -title: "Lifecycle" +title: "Maintenance" description: "How to safely perform maintenance on a Lotus miner." lead: "How to safely perform maintenance on a Lotus miner." draft: false menu: storage-providers: - parent: "storage-providers-configure" + parent: "storage-providers-operate" identifier: "storage-providers-configure-lifecycle" aliases: - /docs/storage-providers/lifecycle/ + - /storage-providers/configure/lifecycle/ weight: 455 toc: true --- diff --git a/content/en/storage-providers/operate/manage-storage-deals.md b/content/en/storage-providers/operate/manage-storage-deals.md index 594a24fa..8cbddacd 100644 --- a/content/en/storage-providers/operate/manage-storage-deals.md +++ b/content/en/storage-providers/operate/manage-storage-deals.md @@ -25,7 +25,7 @@ The following sections provide insights into the different ways Lotus can be use There are two ways to enable and disable new storage deals in the miner. Either: -- Edit the `[DealMaking]` options in the [miner configuration file]({{< relref "configuration" >}}) and [restarting the miner]({{< relref "lifecycle" >}}). +- Edit the `[DealMaking]` options in the [miner configuration file]({{< relref "configuration" >}}) and [restarting the miner]({{< relref "maintenance" >}}). - Using the `lotus-miner storage-deals selection` commands. Since restarting the miner is a delicate operation, it is best to let Lotus handle things by using the `lotus-miner storage-deals selection` commands. diff --git a/content/en/storage-providers/operate/snap-deals/index.md b/content/en/storage-providers/operate/snap-deals/index.md index ad4a15d1..32b65a6a 100644 --- a/content/en/storage-providers/operate/snap-deals/index.md +++ b/content/en/storage-providers/operate/snap-deals/index.md @@ -69,7 +69,7 @@ This is a relatively advanced storage provider operation. Users should be famili You must have the following set up to follow this guide through: -- Lotus 1.14.0 or higher [installed]({{< relref "prerequisites">}}). +- Lotus 1.14.0 or higher [installed]({{< relref "../../../lotus/install/prerequisites">}}). ### Create committed-capacity sectors @@ -199,9 +199,9 @@ A new feature in `lotus-miner` allows converting all the future "CC" sectors to 1. It removes the manual intervention required to convert the "CC" sectors to snap-deal ready sectors and thus, reduces the overhead for the storage provider. 2. As all the new storage deals will be sealed as part of snap-deal, the sealing time would be considerable less. -This new feature can be enabled in the lotus miner [configuration]({{}}). +This new feature can be enabled in the lotus miner [configuration]({{}}). -When a deal enters the the sealing pipeline, lotus-miner will try to match it to any sectors waiting for deals before sealing. If none are found then, lotus-miner will try to check if any `Available` sectors can accept it. It will select a candidate with the lowest initial pledge. If none of the sectors are eligible then a new sector can be created based on the value of `MakeNewSectorForDeals` under [configuration]({{}}). +When a deal enters the the sealing pipeline, lotus-miner will try to match it to any sectors waiting for deals before sealing. If none are found then, lotus-miner will try to check if any `Available` sectors can accept it. It will select a candidate with the lowest initial pledge. If none of the sectors are eligible then a new sector can be created based on the value of `MakeNewSectorForDeals` under [configuration]({{}}). {{< alert >}} In the case that creating new sectors for deals is disabled, the deal will be left hanging until a sector is made "Available" for it. diff --git a/content/en/storage-providers/operate/troubleshooting.md b/content/en/storage-providers/operate/troubleshooting.md index cb102ded..9aae9977 100644 --- a/content/en/storage-providers/operate/troubleshooting.md +++ b/content/en/storage-providers/operate/troubleshooting.md @@ -60,7 +60,7 @@ If you suspect that your GPU is not being used, first make sure it is one or the | N/A | If you see "N/A" for deal success rate, this may be why. Once your miner seals its first sector, the dealbot will start attempting storage deals. From the moment a miner seals its first sector, you should have a storage deal result in max 48 hours (current timeout value for storage deals). For retrieval deals you should see a result in maxim 12 hours after the storage deal is reported successful (current timeout for retrieval deals ). The dashboard currently logs deal **results** only. If you have a storage or retrieval deal in progress you’ll still see “N/A” until it propagates to the chain. | No miner action needed. | | ClientQueryAsk failed : failed to open stream to miner: dial backoff | The connection to the remote host was attempted, but failed. | This may be due to issues with porting, IPs set within the config file, or simply no internet connectivity. To fix, [establish a public IP address](https://docs.filecoin.io/mine/connectivity/#establishing-a-public-ip-address). | | ClientQueryAsk failed : failed to open stream to miner: failed to dial | The deal-bot was unable to open a network socket to the miner. | This is likely because the miner's IP is not publicly dialable, or a port issue. To fix, [establish a public IP address](https://docs.filecoin.io/mine/connectivity/#establishing-a-public-ip-address). | -| ClientQueryAsk failed : failed to open stream to miner: routing: not found | The deal-bot was unable to locate the miners IP and/or port. | Made sure you [published your miner's multiaddresses on the chain]({{< relref "setup#publishing-the-miner-addresses" >}}) | +| ClientQueryAsk failed : failed to open stream to miner: routing: not found | The deal-bot was unable to locate the miners IP and/or port. | Made sure you [published your miner's multiaddresses on the chain]({{< relref "initialize#publishing-the-miner-addresses" >}}) | | ClientQueryAsk failed : failed to read ask response: stream reset | Connectivity loss, either due to a high packet loss rate or libp2p too aggressively dropping/failing connections. | [Fix underway.] Lotus team is currently working on a change to use libp2p's connection tagging feature, which will retry connections if dropped. ([go-fil-markets/#361](https://github.com/filecoin-project/go-fil-markets/issues/361)). No action needed from miners. | | StorageDealError PublishStorageDeals: found message with equal nonce as the one we are looking for | [Under investigation.] We suspect a chain validation error | No action needed from miners. | | ClientMinerQueryOffer - Retrieval query offer errored: get cid info: No state for /bafk2bz... | [Under investigation.] | No action needed from miners. | diff --git a/content/en/storage-providers/operate/upgrades.md b/content/en/storage-providers/operate/upgrades.md index c7bdb293..0a50cd7a 100644 --- a/content/en/storage-providers/operate/upgrades.md +++ b/content/en/storage-providers/operate/upgrades.md @@ -51,10 +51,10 @@ Once you have the default configuration file, compare it with your configuration ## Upgrade in-place -1. Safely shutdown your Lotus Miner as explained [here]({{< relref "lifecycle" >}}). +1. Safely shutdown your Lotus Miner as explained [here]({{< relref "maintenance" >}}). 1. Shutdown any seal workers 1. Shutdown your Lotus Node (`lotus daemon stop` or `systemctl stop lotus-daemon`) -1. Pull the new version and rebuild. For more information read the [Lotus installation guide]({{< relref "prerequisites" >}}) again: +1. Pull the new version and rebuild. For more information read the [Lotus installation guide]({{< relref "../../lotus/install/prerequisites" >}}) again: ```shell export RUSTFLAGS="-C target-cpu=native -g" @@ -95,7 +95,7 @@ lotus-worker run This upgrade procedure should only be used as a last resort or when the chain has been upgraded and requires such action to be taken. {{< /alert >}} -It is similar to re-installing everything from scratch, so you can follow the usual [installation]({{< relref "prerequisites" >}}) and [miner-setup]({{< relref "setup" >}}) guides after it. Before you do this, consider: +It is similar to re-installing everything from scratch, so you can follow the usual [installation]({{< relref "../../lotus/install/prerequisites" >}}) and [miner-setup]({{< relref "initialize" >}}) guides after it. Before you do this, consider: - [Backing up your Lotus wallets]({{< relref "manage-fil#exporting-and-importing-addresses" >}}) - You may want to backup your Lotus Node and Miner configurations as well. diff --git a/content/en/storage-providers/seal-workers/seal-workers.md b/content/en/storage-providers/seal-workers/seal-workers.md index 32d7f4e0..3624eafc 100644 --- a/content/en/storage-providers/seal-workers/seal-workers.md +++ b/content/en/storage-providers/seal-workers/seal-workers.md @@ -57,7 +57,7 @@ If you want to fully delegate any of these operations to workers, set them to `f ### Environment variables -Ensure that workers have access to the following environment variables when they run. These are similar to those used by the Miner daemon ([explained in the setup guide]({{< relref "setup" >}})): +Ensure that workers have access to the following environment variables when they run. These are similar to those used by the Miner daemon ([explained in the setup guide]({{< relref "../setup/initialize" >}})): The seal workers will fail to start if the file descriptor limit is not set high enough. This limit can be raised temporarily before starting the worker by running the command `ulimit -n 1048576`. Although, we recommend setting it permanently by following the [Permanently Setting Your ULIMIT System Value]({{< relref "kb#soft-fd-limit" >}}) guide. diff --git a/content/en/storage-providers/configure/configuration.md b/content/en/storage-providers/setup/configuration.md similarity index 52% rename from content/en/storage-providers/configure/configuration.md rename to content/en/storage-providers/setup/configuration.md index 992d83a5..171bd912 100644 --- a/content/en/storage-providers/configure/configuration.md +++ b/content/en/storage-providers/setup/configuration.md @@ -5,20 +5,21 @@ lead: "This guide covers the Lotus Miner configuration files, detailing the mean draft: false menu: storage-providers: - parent: "storage-providers-configure" - identifier: "storage-providers-configure-configuration" + parent: "storage-providers-setup" + identifier: "storage-providers-setup-configuration" aliases: - /docs/storage-providers/config/ -weight: 110 + - storage-providers/configure/configuration/ +weight: 120 toc: true --- -The Lotus Miner configutation is created after the [initialization step]({{< relref "setup" >}}) during setup and placed in `~/.lotusminer/config.toml` or `$LOTUS_MINER_PATH/config.toml` when defined. +The Lotus Miner configutation is created after the [initialization step]({{< relref "initialize" >}}) during setup and placed in `~/.lotusminer/config.toml` or `$LOTUS_MINER_PATH/config.toml` when defined. The _default configuration_ has all the items commented. To customize one of the items, you must remove the leading `#`. {{< alert >}} -For any configuration changes to take effect, the miner must be [restarted]({{< relref "lifecycle" >}}). +For any configuration changes to take effect, the miner must be [restarted]({{< relref "maintenance" >}}). {{< /alert >}} ## API section @@ -41,7 +42,7 @@ Configure `RemoteListenAddress` to the value that a different node would have to ## Libp2p section -This section configures the miner's embedded Libp2p node. As noted in the [setup instructions]({{< relref "setup" >}}), it is very important to adjust this section with the miner's public IP and a fixed port: +This section configures the miner's embedded Libp2p node. As noted in the [setup instructions]({{< relref "initialize" >}}), it is very important to adjust this section with the miner's public IP and a fixed port: ```toml [Libp2p] @@ -115,159 +116,6 @@ This section allows you to disable subsystems of the `lotus-miner`. #SectorIndexApiInfo = "" ``` -## Dealmaking section - -This section controls parameters for making storage and retrieval deals: - -```toml -[Dealmaking] - # When enabled, the miner can accept online deals - ConsiderOnlineStorageDeals = true - # When enabled, the miner can accept offline deals - ConsiderOfflineStorageDeals = true - # When enabled, the miner can accept retrieval deals - ConsiderOnlineRetrievalDeals = true - # When enabled, the miner can accept offline retrieval deals - ConsiderOfflineRetrievalDeals = true - # When enabled, the miner can accept verified deals - ConsiderVerifiedStorageDeals = true - # When enabled, the miner can accept unverified deals - ConsiderUnverifiedStorageDeals = true - # A list made of Data CIDs to reject when making deals - PieceCidBlocklist = [] - # Maximum expected amount of time getting the deal into a sealed sector will take - # This includes the time the deal will need to get transferred and published - # before being assigned to a sector - # for more info, see below. - ExpectedSealDuration = "24h0m0s" - # When a deal is ready to publish, the amount of time to wait for more - # deals to be ready to publish before publishing them all as a batch - PublishMsgPeriod = "1h0m0s" - # The maximum number of deals to include in a single publish deals message - MaxDealsPerPublishMsg = 8 - - # A command used for fine-grained evaluation of storage deals (see below) - Filter = "/absolute/path/to/storage_filter_program" - - # A command used for fine-grained evaluation of retrieval deals (see below) - RetrievalFilter = "/absolute/path/to/retrieval_filter_program" -``` - -`ExpectedSealDuration` is an estimate of how long sealing will take and is used to reject deals whose start epoch might be earlier than the expected completion of sealing. It can be estimated by [benchmarking]({{< relref "benchmarks" >}}) or by [pledging a sector]({{< relref "sector-pledging" >}}). - -{{< alert icon="warning" >}} -The final value of `ExpectedSealDuration` should equal `(TIME_TO_SEAL_A_SECTOR + WaitDealsDelay) * 1.5`. This equation ensures that the miner does not commit to having the sector sealed too soon. -{{< /alert >}} - -`StartEpochSealingBuffer` allows `lotus-miner` to seal a sector before a certain epoch. For example: if the current epoch is 1000 and a deal within a sector must start on epoch 1500, then `lotus-miner` must wait until the current epoch is 1500 before it can start sealing that sector. However, if `lotus-miner` sets `StartEpochSealingBuffer` to 500, the `lotus-miner` can start sealing the sector at epoch 1000. - -If there are multiple deals in a sector, the deal with a start time closest to the current epoch is what `StartEpochSealingBuffer` will be based off. So, if the sector in our example has three deals that start on epoch 1000, 1200, and 1400, then we `lotus-miner` will start sealing the sector at epoch 500. - -### Disabling new sector for deal - -If `MakeNewSectorForDeals` is set to `true` then `lotus-miner` will create new sectors for incoming deals. This option can set to `false` to ensure that all new deals are sealed as snap-deals into CC sectors. This can help reduce the sealing time for the new deals as long as CC sectors are ready for the snap-deals. - -### Make new CC sector available for snap-deal - -`MakeCCSectorsAvailable` makes all the new CC sectors available to be upgraded with snap-deals. When this boolean is set to `true`, all pledged "CC" sectors from that point onwards will be converted to "Available" state after sealing. This enables sealing the incoming storage deals more quickly into these "Available" sectors compared to creating a new sector for the deals. - -### Publishing several deals in one message - -The `PublishStorageDeals` message can publish multiple deals in a single message. -When a deal is ready to be published, Lotus will wait up to `PublishMsgPeriod` -for other deals to be ready before sending the `PublishStorageDeals` message. - -However, once `MaxDealsPerPublishMsg` is ready, Lotus will immediately publish all the deals. - -For example, if `PublishMsgPeriod` is 1 hour: - -- At 1:00 pm, deal 1 is ready to publish. Lotus will wait until 2:00 pm for other deals to be ready before sending `PublishStorageDeals`. -- At 1:30 pm, Deal 2 is ready to publish -- At 1:45 pm, Deal 3 is ready to publish -- At 2:00pm, lotus publishes Deals 1, 2, and 3 in a single `PublishStorageDeals` message. - -If `MaxDealsPerPublishMsg` is 2, then in the above example, when deal 2 is ready to be published at 1:30, Lotus would immediately publish Deals 1 & 2 in a single `PublishStorageDeals` message. Deal 3 would be published in a subsequent `PublishStorageDeals` message. - -> If any of the deals in the `PublishStorageDeals` fails validation upon execution, or if the start epoch has passed, all deals will fail to be published. - -## Using filters for fine-grained storage and retrieval deal acceptance - -Your use case might demand very precise and dynamic control over a combination of deal parameters. - -Lotus provides two IPC hooks allowing you to name a command to execute for every deal before the miner accepts it: - -- `Filter` for storage deals. -- `RetrievalFilter` for retrieval deals. - -The executed command receives a JSON representation of the deal parameters on standard input, and upon completion, its exit code is interpreted as: - -- `0`: success, proceed with the deal. -- `non-0`: failure, reject the deal. - -The most trivial filter rejecting any retrieval deal would be something like: -`RetrievalFilter = "/bin/false"`. `/bin/false` is binary that immediately exits with a code of `1`. - -[This Perl script](https://gist.github.com/ribasushi/53b7383aeb6e6f9b030210f4d64351d5/9bd6e898f94d20b50e7c7586dc8b8f3a45dab07c#file-dealfilter-pl) lets the miner deny specific clients and only accept deals that are set to start relatively soon. - -You can also use a third party content policy framework like `bitscreen` by Murmuration Labs: - -```shell -# grab filter program -go get -u -v github.com/Murmuration-Labs/bitscreen - -# add it to both filters -Filter = "/path/to/go/bin/bitscreen" -RetrievalFilter = "/path/to/go/bin/bitscreen" -``` - -## Index Provider section - -This section controls the behavior around the Index Provider: - -```toml -[IndexProvider] - # Enable set whether to enable indexing announcement to the network and expose endpoints that - # allow indexer nodes to process announcements. Disabled by default. - # - # type: bool - # env var: LOTUS_INDEXPROVIDER_ENABLE - #Enable = true - - # EntriesCacheCapacity sets the maximum capacity to use for caching the indexing advertisement - # entries. Defaults to 1024 if not specified. The cache is evicted using LRU policy. The - # maximum storage used by the cache is a factor of EntriesCacheCapacity, EntriesChunkSize and - # the length of multihashes being advertised. For example, advertising 128-bit long multihashes - # with the default EntriesCacheCapacity, and EntriesChunkSize means the cache size can grow to - # 256MiB when full. - # - # type: int - # env var: LOTUS_INDEXPROVIDER_ENTRIESCACHECAPACITY - #EntriesCacheCapacity = 1024 - - # EntriesChunkSize sets the maximum number of multihashes to include in a single entries chunk. - # Defaults to 16384 if not specified. Note that chunks are chained together for indexing - # advertisements that include more multihashes than the configured EntriesChunkSize. - # - # type: int - # env var: LOTUS_INDEXPROVIDER_ENTRIESCHUNKSIZE - #EntriesChunkSize = 16384 - - # TopicName sets the topic name on which the changes to the advertised content are announced. - # Defaults to '/indexer/ingest/mainnet' if not specified. - # - # type: string - # env var: LOTUS_INDEXPROVIDER_TOPICNAME - #TopicName = "/indexer/ingest/mainnet" - - # PurgeCacheOnStart sets whether to clear any cached entries chunks when the provider engine - # starts. By default, the cache is rehydrated from previously cached entries stored in - # datastore if any is present. - # - # type: bool - # env var: LOTUS_INDEXPROVIDER_PURGECACHEONSTART - #PurgeCacheOnStart = false -``` - ## Proving section This section controls some of the behavior around windowPoSt: @@ -281,239 +129,6 @@ This section controls some of the behavior around windowPoSt: #ParallelCheckLimit = 128 ``` -## Sealing section - -This section controls some of the behavior around sector sealing: - -```toml -[Sealing] - # Upper bound on how many sectors can be waiting for more deals to be packed in it before it begins sealing at any given time. - # If the miner is accepting multiple deals in parallel, up to MaxWaitDealsSectors of new sectors will be created. - # If more than MaxWaitDealsSectors deals are accepted in parallel, only MaxWaitDealsSectors deals will be processed in parallel - # Note that setting this number too high in relation to deal ingestion rate may result in poor sector packing efficiency - MaxWaitDealsSectors = 2 - # Upper bound on how many sectors can be sealing at the same time when creating new CC sectors (0 = unlimited) - MaxSealingSectors = 0 - # Upper bound on how many sectors can be sealing at the same time when creating new sectors with deals (0 = unlimited) - MaxSealingSectorsForDeals = 0 - # CommittedCapacitySectorLifetime is the duration a Committed Capacity (CC) sector will - # live before it must be extended or converted into sector containing deals before it is - # terminated. Value must be between 180-540 days inclusive - # - # type: Duration - CommittedCapacitySectorLifetime = "12960h0m0s" - - # Period of time that a newly created sector will wait for more deals to be packed in to before it starts to seal. - # Sectors which are fully filled will start sealing immediately - WaitDealsDelay = "6h0m0s" - # Whether to keep unsealed copies of deal data regardless of whether the client requested that. This lets the miner - # avoid the relatively high cost of unsealing the data later, at the cost of more storage space - AlwaysKeepUnsealedCopy = true - # Run sector finalization before submitting sector proof to the chain - FinalizeEarly = false - # Whether to use available miner balance for sector collateral instead of sending it with each message - CollateralFromMinerBalance = false - # Minimum available balance to keep in the miner actor before sending it with messages - AvailableBalanceBuffer = 0 - # Don't send collateral with messages even if there is no available balance in the miner actor - DisableCollateralFallback = false - # enable / disable precommit batching (takes effect after nv13) - BatchPreCommits = true - # maximum precommit batch size up to 256 sectors - batches will be sent immediately above this size - MaxPreCommitBatch = 256 - # how long to wait before submitting a batch after crossing the minimum batch size - PreCommitBatchWait = "24h0m0s" - # time buffer for forceful batch submission before sectors/deal in batch would start expiring - PreCommitBatchSlack = "3h0m0s" - - # enable / disable commit aggregation (takes effect after nv13) - AggregateCommits = true - # minimum batched commit size, no less than 4 - MinCommitBatch = 4 - # maximum batched commit size up to 819 sectors - batches will be sent immediately above this size - MaxCommitBatch = 819 - # how long to wait before submitting a batch after crossing the minimum batch size - CommitBatchWait = "24h0m0s" - # time buffer for forceful batch submission before sectors/deals in batch would start expiring - CommitBatchSlack = "1h0m0s" - - # network BaseFee below which to stop doing commit aggregation, instead submitting proofs to the chain individually - AggregateAboveBaseFee = 0.00000000015 #0.15nano - - - TerminateBatchMax = 100 - TerminateBatchMin = 1 - TerminateBatchWait = "5m0s" -``` - -### PreCommitSectorsBatch - -`PreCommitSectorsBatch` introduced by [FIP-0008 ](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0008.md) supports a miner to pre-commit a number of sectors at once. - -In lotus v1.10.0 and up, if `BatchPreCommit` is set to false, pre-commitments will be sent to the chain via `PreCommitSector` messages once they are ready. If `BatchPreCommit` is set to true, lotus will batch pre-commitments until any of `MaxPreCommitBatch`, `PreCommitBatchWait` or `PreCommitBatchSlack` is hit: -- `MaxPreCommitBatch` is the maximum amount of sectors' pre-commitments to batch in one `PreCommitSectorsBatch` message. According to FIP-0008, this values is up to 256. -- `PreCommitBatchWait` is how long to wait before submitting the current batch. Note: the ticket of pre-commitment has an expiration of approximately **31.5 hours**, one sector's pre-commit ticket expires **WILL** cause the whole message to fail. Therefore, **we recommend miners to set this value lower than 30 hours.** -- `PreCommitBatchSlack` is the time buffer to forcefully submit the current batch before any of the sector's pre-commit ticket or a deal will expire. For example, if this value is set to 1 hour, which is 120 epochs, then a `PreCommitSectorsBatch` message will be submitted for the existing batch 120 epochs before the earliest epoch among precommits' tickets and deal's start epochs in this batch. **We recommend you to set a longer slack to prevent message failures due to expirations.** - -> Note, the current batch will be sent if any of `MaxPreCommitBatch`, `PreCommitBatchWait` or `PreCommitBatchSlack` is hit. - -To check the list of the sectors pre-commitments that are in the batching queue, run: - -```shell -./lotus-miner sectors batching precommit -``` - -This will output the sector IDs: - -```shell -14 -15 -16 -``` - -To ignore the configuration and force push the current batch, run: - -```shell -./lotus-miner sectors batching precommit --publish-now=true -``` - -Then in the output, the message CID of the `PreCommitSectorsBatch` message and the sector number of the sectors' pre-commitments that are being submitted is listed: - -```shell -Batch 0: - Message: bafy2bzacecgihnlvbsqu7yksco3vs5tzk3ublbcnkedlofr6nhbq55k5ye3ci - Sectors: - 14 OK - 15 OK - 16 OK -``` - -### ProveCommitAggregate - -`ProveCommitAggregate` introduced by [FIP-0013](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0013.md) supports a miner to prove-commit a number of sectors at ones. - -In Lotus v1.10.0 and up, if `AggregateCommits` is set to false, prove-commitments will be sent to the chain via `ProveCommitSector` messages once they are ready. If `AggregateCommits` is set to true, lotus will aggregate and batch pre-commitments until any of `MaxCommitBatch`, `CommitBatchWait` or `CommitBatchSlack` is hit: -- `MaxCommitBatch` is the maximum amount of sectors' prove-commitments to batch in one `ProveCommitAggregate` message. According to FIP-0013, this value is up to 819. -- `CommitBatchWait` is how long to wait before submitting the current batch **after** crossing `MinCommitBatch`. Note: a prove-commitment must be submitted **within 30 days** after the pre-commit has landed on-chain. It is recommended to set this value lower than 30 days to prevent collateral loss. -- `CommitBatchSlack` is the time buffer to forcefully submit the current batch before any of the sector's pre-commitment or a deal will expire. For example, if this value is set to 1 hour, which is 120 epochs, then a `ProveCommitAggregate` message will be submitted for the existing batch 120 epochs before the earliest epoch among precommits' expirations and deals' start epochs in this batch. **We recommend you to set a longer slack to prevent message failures due to deal expirations or loss of collateral** -- `AggregateAboveBaseFee` is the network base fee to start aggregating proofs. When the network base fee is lower than this value, the prove commits will be submitted individually via `ProveCommitSector`. **According to the [Batch Incentive Alignment](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0013.md#batch-incentive-alignment) introduced in FIP-0013, we recommend you to set this value to 0.15 nanoFIL to avoid unexpected aggregation fee in burn.** - -`MinCommitBatch` is the minimum amount of sectors' prove-commitment to be batched in one `ProveCommitAggregate` message. According to FIP-0013, this value cannot be less than 4, which is the cross-over point where prove-commit aggregation wins out on single prove-commit gas costs. If any of `MaxCommitBatch`, `CommitBatchWait` or `CommitBatchSlack` is hit by the amount of prove-commit is the batching queue is less than `MinCommitBatch`, then prove-commitments in this batch will be proceeded individually via `ProveCommitSector`. - -> Note: Aggregated proofs will incur a discounted Gas Charge, so overall, it will be less gas usage than the same number of proofs on-chain, but a minimum fee will apply. It is _cheaper per proof_ to aggregate more proofs into a single aggregate message, meaning aggregating 1000 proofs is more beneficial than aggregating 10 sectors. So if a miner wants to onboard more storage, it is recommended to aggregate more proofs into a single message. - -To check the list of the sectors prove-commitments that are in the batching queue, run: - -```shell -./lotus-miner sectors batching commit -``` - -This will output something like: - -```shell -10 -11 -12 -13 -14 -15 -16 -17 -``` - -To ignore the configuration and force push the current batch, run: - -```shell -./lotus-miner sectors batching commit --publish-now=true -``` - -Then in the output, the message CID of the `ProveCommitAggregate` message and the sector number of the sectors' prove-commitments that are being submitted is listed: - -```shell -Batch 0: - Message: bafy2bzacedtmykgf5g4evdvapacpmo4l32ewu5l7yxqkzjh3h6fhev7v7qoys - Sectors: - 15 OK - 17 OK - 12 OK - 10 OK - 11 OK - 13 OK - 16 OK - 14 OK -``` - -If the sectors in the queue are less than `MinCommitBatch`, then individual `ProveCommitSector` messages will be sent for each sector: - -```shell -Batch 0: - Message: bafy2bzacedpwysxdsg2ft3hfbwn6ayyaanivfwkx4inav3zm34hwmmwgsljkk - Sectors: - 18 OK -Batch 1: - Message: bafy2bzacedrx7l34ckaue7hm2ubousl3djuigyu2xw4xzywgkhttxecsm5ba2 - Sectors: - 19 OK -``` - -### CommittedCapacitySectorLifetime - -The available units are: - -```shell -"ms": int64(Millisecond), - "s": int64(Second), - "m": int64(Minute), - "h": int64(Hour), -``` - -For example, if you want to set the sector lifecycle to 180 days, you can multiply 180 days by 24 hours per day to get 4320 hours and set this value to `"4320h0m0s"`. - -## Storage section - -The storage sector controls whether the miner can perform certain sealing actions. Depending on the setup and the use of additional [seal workers]({{< relref "seal-workers" >}}), you may want to modify some of the options. - -```toml -[Storage] - # Upper bound on how many sectors can be fetched in parallel by the storage system at a time - ParallelFetchLimit = 10 - # Sealing steps that the miner can perform itself. Sometimes we have a dedicated seal worker to do them and do not want the miner to commit any resources for this. - AllowAddPiece = true - AllowPreCommit1 = true - AllowPreCommit2 = true - AllowCommit = true - AllowUnseal = true -``` - -## Fees section - -The fees section allows to set limits to the gas consumption for the different messages that are submitted to the chain by the miner: - -```toml -[Fees] - # Maximum fees to pay - MaxPreCommitGasFee = "0.025 FIL" - MaxCommitGasFee = "0.05 FIL" - MaxTerminateGasFee = "0.5 FIL" - # This is a high-value operation, so the default fee is higher. - MaxWindowPoStGasFee = "5 FIL" - MaxPublishDealsFee = "0.05 FIL" - MaxMarketBalanceAddFee = "0.007 FIL" - [Fees.MaxPreCommitBatchGasFee] - Base = "0 FIL" - PerSector = "0.02 FIL" - [Fees.MaxCommitBatchGasFee] - Base = "0 FIL" - PerSector = "0.03 FIL" - -``` - -Depending on the network congestion, the base fee for a message may grow or decrease. Your gas limits will have to be larger than the base fee for the messages to be included. A very large max fee can, however, result in the quick burning of funds when the base fee is very high, as the miner automatically submits messages during normal operation, so be careful about this. It is also necessary to have more funds available than any max fee set, even if the actual fee will be far less than the max fee set. - -Set the maximum cost you are willing to pay for onboarding **per** sector in `MaxPreCommitBatchGasFee.PerSector`/`MaxCommitBatchGasFee.PerSector` to avoid unexpected high costs. - -> Note: The current `MaxCommitBatchGasFee.PerSector` is enough to aggregate proofs for 6 sectors. Adjust this respectively according to your operation. **If the value is too low, the message may wait in the mempool for a long while. If you don't have enough funds, the message will not be sent.** - ## Addresses section The addresses section allows users to specify additional addresses to send messages from. This helps mitigate head-of-line blocking for important messages when network fees are high. For more details see the [Miner addresses]({{< relref "addresses" >}}) section. diff --git a/content/en/storage-providers/setup/initialize.md b/content/en/storage-providers/setup/initialize.md new file mode 100644 index 00000000..0717b4c0 --- /dev/null +++ b/content/en/storage-providers/setup/initialize.md @@ -0,0 +1,103 @@ +--- +title: "Initialize" +description: "This guide describes the necessary steps to configure a Lotus miner for production." +lead: "This guide describes the necessary steps to configure a Lotus miner for production." +draft: false +menu: + storage-providers: + parent: "storage-providers-setup" + identifier: "storage-providers-setup-initialize" +aliases: + - /docs/storage-providers/setup/ + - /storage-providers/configure/setup/ +weight: 110 +toc: true +--- + +## Checklist before launch + +To summarize, make sure that: + +- All the [prerequisite steps]({{< relref "prerequisites">}}) have been completed. +- The _worker address_ has some funds so that the miner can be initialized. +- The following environment variables have been defined and will be available for all Lotus miner instances: + + ```plaintext + export LOTUS_MINER_PATH=/path/to/miner/config/storage + export LOTUS_PATH=/path/to/lotus/node/folder # When using a local node. + export BELLMAN_CPU_UTILIZATION=0.875 # Optimal value depends on your exact hardware. + export FIL_PROOFS_MAXIMIZE_CACHING=1 + export FIL_PROOFS_USE_GPU_COLUMN_BUILDER=1 # When having GPU. + export FIL_PROOFS_USE_GPU_TREE_BUILDER=1 # When having GPU. + export FIL_PROOFS_PARAMETER_CACHE=/fast/disk/folder # > 100GiB! + export FIL_PROOFS_PARENT_CACHE=/fast/disk/folder2 # > 50GiB! + ``` + +- Parameters have been prefetched to the cache folders specified above. +- The system has enough swap and it is active. +- The lotus api has been configured and the variable has been exported in the environment where lotus miner runs. +- Wallets have been created for the owner and worker address. + +## Miner initialization + +Before starting your miner for the first time run: + +```shell +lotus-miner init --owner=
--worker=
--no-local-storage +``` + +- The `--no-local-storage` flag is used so that we can later configure [specific locations for storage]({{< relref "custom-storage-layout" >}}). This is optional but recommended. +- The Lotus Miner configuration folder is created in `~/.lotusminer/` or `$LOTUS_MINER_PATH` if set. +- The difference between _owner_ and _worker_ addresses is explained in the [miner addresses guide]({{< relref "addresses" >}}). As mentioned above, we recommend using two separate addresses. If the `--worker` flag is not provided, the owner address will be used. _Control addresses_ can be added later when the miner is running. + +## Connectivity to the miner + +Before you start your miner, it is important to configure it so that it is reachable from any peer in the Filecoin network. For this, you will need a stable public IP and edit your `~/.lotusminer/config.toml` as follows: + +```toml +... +[Libp2p] + ListenAddresses = ["/ip4/0.0.0.0/tcp/24001"] # choose a fixed port + AnnounceAddresses = ["/ip4//tcp/24001"] # important! +... +``` + +Once you start your miner, [make sure you can connect to its public IP/port]({{< relref "connectivity" >}}). + +## Starting the miner + +You are now ready to start your Lotus miner: + +```shell +lotus-miner run +``` + +or if you are using the systemd service file: + +```shell +systemctl start lotus-miner +``` + +{{< alert icon="warning" >}} +**Do not proceed** from here until you have verified that your miner not only is running, but also [reachable on its public IP address]({{< relref "connectivity" >}}). +{{< /alert >}} + +## Publishing the miner addresses + +Once the miner is up and running, publish your miner address (which you configured above) to the chain so that other nodes can talk to it directly and make deals: + +```shell +lotus-miner actor set-addrs /ip4//tcp/24001 +``` + +## Next steps + +Your miner should now be preliminarily set up and running, but **there are still a few more recommended tasks** to be ready for prime-time: + +- Set up your [custom storage layout]({{< relref "custom-storage-layout" >}}) (required if you used `--no-local-storage`). +- Edit the miner [configuration settings]({{< relref "configuration" >}}) to fit your requirements. +- Learn when to safely [shut down/restart your miner]({{< relref "maintenance" >}}) +- Update `ExpectedSealDuration` with the time it takes your miner to seal a sector: discover it by [running a benchmark]({{< relref "benchmarks" >}}) or by [pledging a sector]({{< relref "sector-pledging" >}}) and noting down the time. +- Configure additional [seal workers]({{< relref "seal-workers" >}}) to increase the miner's capacity to seal sectors. +- Configure a [separate address for WindowPost messages]({{< relref "addresses" >}}). +- Consider [splitting markets and miners processes]({{< relref "split-markets-miners" >}}) for increased stability. diff --git a/content/en/storage-providers/setup/prerequisites.md b/content/en/storage-providers/setup/prerequisites.md new file mode 100644 index 00000000..a374503b --- /dev/null +++ b/content/en/storage-providers/setup/prerequisites.md @@ -0,0 +1,154 @@ +--- +title: "Prerequisites" +description: "This guide describes the necessary prerequisites before configuring a Lotus miner for production." +lead: "This guide describes the necessary prerequisites before configuring a Lotus miner for production.." +draft: false +menu: + storage-providers: + parent: "storage-providers-setup" + identifier: "storage-providers-setup-prerequisites" +weight: 100 +toc: true +--- + +Mining will only work if you fully comply with the [minimal hardware requirements]({{< relref "hardware-requirements" >}}) for the network in which you will mine. The mining process is very resource-intensive and is dependent on precise configuration. We strongly recommend Linux systems administration experience before embarking. + +{{< alert icon="callout" >}} +Be warned: if you decide to skip any of the sections below, things will not work! Read and tread carefully. +{{< /alert >}} + +## Neccessary prerequisites + +These steps must be performed to sucessfully intialize a lotus miner. + +### Basic Prerequisites + +Please make sure that the following prerequites are met whether you are planning to run the lotus miner on the same machine as lotus daemon or a different machine. + +1. Install the latest stable [Nvidia drivers and Cuda]({{< relref "../../tutorials/lotus-miner/cuda" >}}) if you have an Nvidia card on your machine. Nvidia cards have a better performance with Cuda when compared to OpenCL. +2. Make sure you have followed the instructions to [install the Lotus suite]({{< relref "../../lotus/install/prerequisites" >}}) to build the `lotus-miner` binary. Make sure that you have built Lotus with "Native Filecoin FFI" and exported the following variable to compile FFI to use Cuda if using Nvidia cards. + + ```shell + export FFI_USE_CUDA=1 + ``` + + Please do not use the `lotus-miner` binary created during Lotus node installation process as it does not include the above options. + +3. Make sure your Lotus Node is running as the miner will communicate with it and cannot work otherwise. +4. If you are in China, read the [tips for running in China]({{< relref "../../lotus/install/prerequisites#node-in-china" >}}) page first. +5. Make sure to [add swap]({{< relref "../../kb/add-swap" >}}) to the machine as required. + +### Running the miner on a different machine as the Lotus Node + +If you opt to run a miner on a different machine as the Lotus Node, set: + +```shell +export FULLNODE_API_INFO=:/ip4//tcp//http +``` + +Make sure the `ListenAddress` has [remote access enabled]({{< relref "../../developers/api-access#enable-remote-api-access" >}}). Instructions on how to obtain a token are [available here]({{< relref "api-access#obtaining-tokens" >}}). + +### Performance tweaks + +It is recommended to set the following environment variables in your environment so that they are defined every time any of the `lotus` daemons are launched: + +```shell +# See https://github.com/filecoin-project/rust-fil-proofs/ +export FIL_PROOFS_MAXIMIZE_CACHING=1 # More speed at RAM cost (1x sector-size of RAM - 32 GB). +export FIL_PROOFS_USE_GPU_COLUMN_BUILDER=1 # precommit2 GPU acceleration +export FIL_PROOFS_USE_GPU_TREE_BUILDER=1 + +# The following increases speed of PreCommit1 at the cost of using a full +# CPU Core-Complex rather than a single core. Should be used with CPU affinities set! +# See https://github.com/filecoin-project/rust-fil-proofs/ and the seal workers guide. +export FIL_PROOFS_USE_MULTICORE_SDR=1 +``` + +### Cuda variables + +There are some changes in the latest Nvidia driver, so if you upgrade your driver remember to check `nvidia-smi` - it will always display the correct name for the GPU. The new names are not picked by FFI automatically and need to be exported manually. + +If you are using an nvidia driver below `460.91.03` + +```shell +export BELLMAN_CUSTOM_GPU="GeForce RTX 3090:10496" +``` + +If you are using an Nvidia driver above `510.47.03` + +```shell +export BELLMAN_CUSTOM_GPU="NVIDIA GeForce RTX 3090:10496" +``` + +Nvidia RTX 3090 was used in this example. Remember to edit it with your GPU and amount of Cuda cores. + +### Configure parameters location + +For the miner to start, it will need to read and verify the Filecoin proof parameters. These can be downloaded in advance (recommended), or otherwise the init process will. Proof parameters consist of several files, which in the case of 32 GiB sectors, total **over 100 GiB**. + +We recommend setting a custom location to store parameters and proofs parent cache -created during the first run- with: + +```shell +export FIL_PROOFS_PARAMETER_CACHE=/path/to/folder/in/fast/disk +export FIL_PROOFS_PARENT_CACHE=/path/to/folder/in/fast/disk2 +``` + +Parameters are read on every (re)start, so using disks with very fast access, like NVMe drives, will speed up miners and workers (re)boots. When the above variables are not set, things will end up in `/var/tmp/` by default, which **often lacks enough space**. + +Parameters will be downloaded automatically when the miner is initiated. You can also [optionally download]({{< relref "#downloading-parameters" >}}) them before initializing. + +### Creating wallets for the miner + +You will need at least a BLS wallet (`f3...` for mainnet) for mining. We recommend using [separate owner and worker addresses]({{< relref "addresses" >}}): + +```shell +# A new BLS address to use as owner address: +lotus wallet new bls +f3... + +# A new BLS address to use as worker address: +lotus wallet new bls +f3... +``` + +{{< alert icon="callout" >}} +Next make sure to [send some funds]({{< relref "manage-fil" >}}) to the **worker address** so that the miner setup can be completed. The amount you should initialize with varies with gas fees, but 0.1 FIL is generally a safe amount. The sender doesn't have to be any particular address and can be specified using the `from` flag. If `from` is unspecified, the sender will default to the `owner` address, in which case the `onwer` must have the 0.1 FIL. If the `owner` is also unspecified, the wallet's default address is used as the owner and that address must have the 0.1 FIL. +{{< /alert >}} + +For additional information about the different wallets that a miner can use and how to configure them, read the [miner addresses guide]({{< relref "addresses" >}}). + +{{< alert icon="tip" >}} +Safely [backup your wallets]({{< relref "manage-fil#exporting-and-importing-addresses" >}})! +{{< /alert >}} +## Optional prerequisites + +These prerequisites are optional and can be used on a case by case basis. Please make sure to understand the use case before performing these steps. + +### Install extra dependencies + +This step is only necessary if you are running an Nvidia GPU and would prefer to use OpenCL instead of CUDA. Please note that Cuda is recommended over OpenCL for sealing and proving workload. Most Linux distributions contain this package in their package manager: + +```shell +sudo apt update -y && sudo apt install -y nvidia-opencl-icd -y +``` + +### Optional Performance tweaks + +```shell +# See https://github.com/filecoin-project/bellman +export BELLMAN_CPU_UTILIZATION=0.875 +``` + +The `BELLMAN_CPU_UTILIZATION` is an optional variable to designate a proportion of the multi-exponentiation calculation to be moved to a CPU in parallel to the GPU. This is an effort to keep all the hardware occupied. The interval must be a number between `0` and `1`. The value `0.875` is a good starting point, but you should experiment with it if you want an optimal setting. Different hardware setups wil +l result in different values being optimal. Omitting this environment variable might also be optimal. + +### Downloading parameters + +To download the parameters do: + +```shell +# Use sectors supported by the Filecoin network that the miner will join and use. +# lotus-miner fetch-params +lotus-miner fetch-params 32GiB +lotus-miner fetch-params 64GiB +```