Product comparison between Lotus and Venus / Venus' solutions to common problems of SPs

[Fatman13]

This is a product comparison between Lotus and Venus. For Venus' solutions to common problems of SPs, please checkout this digest.

Background

Community has always wondered the sealing experience difference between Lotus and Venus. And the team has received requests from different sources to have a quick overview comparison.

Product Comparison

1) Sealing Task Scheduling

-- For Lotus:

In both large and smaller SP deployments, one can observe that there are lags in what resources a lotus-worker reports it has available. Lotus-Workers need to be allocated tasks more efficiently. There is a big discrepancy between the theoretical throughput a sealing worker can have and the actual throughput. These inefficiencies compounds for storage providers wanting to scale fast, or that need to have a high deal/sealing throughput (i.e many lotus-workers).

All scheduling is currently done on the Lotus-Miner process. This process does not have perfect information about each lotus-worker state, which means that it has to model each of the Lotus-Workers states. This leads to the scheduling logic being complex and inevitably not having a perfect state of the workers.

The scheduler also has an upper boundary of how many lotus-workers it's built for. There are currently many network roundtrips involved in the scheduling logic for a single process, which leads to a theoretically supported upper boundary of 100 Lotus-Workers. We have seen Storage Providers run with more workers than this, but additional issues observed grow exponentially from this point.

-- For Venus:

Taking advantage of working closely with SPs large (enterprise) and small, Venus has reimagined scheduling architecture which allows enterprise SPs to have a much more efficient usage of their hardwares, thus increasing their overall sealing throughput.

By allowing workers to change the state machine of a sealing sector, instead of having an active and centralized job scheduling model, Damocles (venus-cluster) introduced a new model that worker itself actively grabs new tasks.

The extensive configuration options and all sealing phases in one worker design of the new architecture enable SPs to scale fast. Increasing capacity of sealing pipeline is easy and manageable without having to tweak performance each time when adding new boxes to the pipeline.

2) PoSt redundancy support

-- For Lotus:

Proving your storage is a critical component for storage providers, and failure to post WindowPoSt poses great earnings loss and costs. Today you can connect multiple windowPoSt workers to a single Lotus-Miner instance, which allows storage providers to have many partitions in a single deadline, enabling one to scale up to large raw storage capacities. This is still only partially useful at an enterprise scale since there is no redundancy in windowPoSt. There is also no redundancy in winningPoSt.

-- For Venus:

Venus' new innovative architecture allows users to write their own wdPost strategy to their own likings. For example, It would be very easy for user to arrange a custom master and slave strategy where slaves would get wdPost task from master, therefore failure of a slave box would not jeopardize the whole storage providing operation.

3) multiple MinerIDs

-- For Lotus:

Enterprise Storage Providers might take on funding from multiple investors or different lending platforms. A common way of managing funds from these different entities (and also managing risk), is to separate funds/ownership between different MinerIDs. The storage providers usually have a fixed amount of sealing workers and storage servers which they then spread across these MinerIDs. Managing all these workers and changing workers to different MinerIDs is both time consuming and not very flexible. The same issue also arises for storage providers running test networks, as the MinerID for the test network would need a dedicated sealing-pipeline and storage.

-- For Venus:

Through Venus' original architecture and broad selection of configurations, user can quickly organize a pool of venus-workers into effectively a private SaaS (sealing-as-a-service) service that can be used to seal for multiple miner_ids at the same time, thus saving SPs both CapEx and OpEx.

4) Snapdeal

In the context of Snapdeal sealing experiences for Lotus, the support for SnapDeal is limited to manual efforts through command line. Whereas, Venus was designed to provide an enterprise SnapDeal solution that does not require manual intervention, which we call SnapUp. Its steps are roughly as follows:

• Batch import existing CC sectors as local candidate sectors
• Configure venus-sector-manager to enable SnapUp support for the specified SP
• Configure venus-worker to convert existing sealing_thread into SnapUp production plan, or add sealing_thread for SnapUp. During the whole process, users only need to pay attention to the import and remaining of local candidate sectors, and venus-cluster will be taking care of the rest.

Resources

• Architectural/System-level problems for enterprise-level Storage Providers lotus#9686

[Fatman13]

This is Venus' solutions to common problems of SPs. For product comparison between Lotus and Venus, please check out this digest.

Venus' solutions to common problems of SPs

1) Failures of Snapdeals. I snap deal to my CC sectors, but I sometimes fail when I do it on a large scale.

There are different possible reasons causing the failure: message sending or local task scheduling. But the most common reason is sealing task scheduling.

Venus fix it on a fundamental level that Venus by design having sectors actively grab their tasks so that the task-scheduling caused snapdeal failure will never happen among Venus SPs.

Some may also ask if I don't want to use command line to manually arrange the Snapdeal tasks, is there any tool that I can use?

Yes, Venus also provides an enterprise SnapDeal solution that does not require manual intervention, which we call SnapUp.

2) I have multiple MinerIDs. When I finish sealing one of the MinerIDs, I have to physically move the sealing workers and connect to the other MinerID. It's time consuming and not easy to manage because it would involve extra onsite support.

Through Venus' original architecture and broad selection of configurations, user can quickly organize a pool of sealing workers into effectively a private SaaS (sealing-as-a-service) service that can be used to seal for multiple miner_ids at the same time, thus saving SPs both capex and opex.

3) My node loses storage power and fails to produce blocks from time to time. No backup PoST worker problem

Venus' new innovative architecture allows users to write their own wdPost strategy to their own likings. For example, it would be very easy for users to arrange a custom master and slave strategy where slaves would get wdPost task from master, therefore failure of a slave box would not jeopardize the whole storage providing operation.

4) My node periodically goes out of sync and causes me orphan block. Node server connection problem

A module called Chain-co that is compatible with Venus (for now) can fix many connecting problems between node server and filecoin chain. Chain-co deal with it through a high availability method that can automatically switch the work between several different node servers. When the defuat node server is down, Chain-co will automatically switch to another node server to secure the interaction between the Miner and filecoin chain. By doing that, SPs who are running Venus can avoid single point failure of the node servers thus improving the stability of storage providing.

5) I see some SPs using Venus with the same hardwares have faster sealing speed. Why?

Damocles made the sealing faster. Damocles is a set of modules that are compatible with Venus only and deployed by SPs locally.
Venus community did a test to identify the sealing speed difference between lotus-sealer and Damocles (venus-cluster). The result is that under most circumstances, Damocles seals equally or faster compared to lotus-sealer. The difference comes from the task scheduling function of Damocles which optimizes the sealing pipeline for SPs.

6) I received a large amount of data from a client, I want to divide the large amount of data into several parts and send these deals to different MinerIDs at scale.

It can be done by SPs who are running Venus. Venus has Droplet(venus-market) to optimize deal making pipeline. For example, for a SP running a Sophon node (Venus Chain Servie) with 10 different MinerIDs(Damocles cluster) sharing Sophon service at different locations/data centers. Droplet helps SP to easily distribute the Datacap deals to multiple nodes.

[caijian76]

I feel venus is much more convenient than lotus, being able to manage my more miners on one server ,and have professional support team for me .

[litai686]

Venus splits all functions into more details, which is suitable for large-scale management, but it increases the difficulty for operation and maintenance personnel to get started. Lotus is relatively easy to master for small-scale SPs.

With regard to the market, Venus is more flexible in deployment after the update of V.2.4.0, especially snap. Venus is very friendly in design. Lotus is not perfect, The two online issuing clients still need to be optimized for transmission.

Suggestions on winPost or winningPost ：https://filecoinproject.slack.com/archives/C028PCH8L31/p1665364428622529?thread_ts=1665305383.988059&cid=C028PCH8L31

[pandacrypto]

@Fatman13 Hi; apologies for sending a message here. I want to contact you to discuss Venus vs. Lotus more, and we want to invite you as a speaker to a webinar. Feel free to contact me at Filecoin Slack workspace: Wayne Tang or email: ueinto1986@gmail.com