filecoin-project / oni

👹 (DEPRECATED; see README) Project Oni | Network Validation
https://docs.google.com/document/d/16jYL--EWYpJhxT9bakYq7ZBGLQ9SB940Wd1lTDOAbNE
7 stars 5 forks source link

[test scenario] standard/fast retrieval A/B benchmarking #150

Open raulk opened 4 years ago

raulk commented 4 years ago

Describe the test scenario.

"Fast retrieval" is the process of requesting a storage miner to keep the data in a hot store (unsealed), such that retrieval will not require unsealing. Fast retrieval is requested by the client in their deal proposal, and it is expected that the miner will increase their ask price, as they now have to keep two copies of the data (unsealed, and sealed).

(It doesn't go on chain, therefore there are no consequences if the miner does not hold up their end of the bargain, until we have some reputation market somewhere, or something.)

Reference: https://github.com/filecoin-project/lotus/pull/2323.

image

Via CLI, it’s literally just adding --fast-retrieval when proposing a deal.

Provide any background and technical implementation details.

Basically, 1 miner, 1 client, 2 deals. one deal is slow, one deal is fast. Once both deals are made, we clear this CID from the provider blockstore. Then we retrieve each, and measure the time it takes.

Perform many iterations to get a good quality statistical reading.

Our usage of 2k sectors might be an impediment, though. We might need to use larger sectors for this test to be meaningful.

What should we measure?

Time taken to retrieve each type of deal, from the same miner.

Discomfort factor (0-10).

Additional remarks.

Stakeholder: @pooja.

pooja commented 4 years ago

I think you don't actually have to specify the flag to enable this retrieval option. It's enabled by default and you would have to set --fast-retrieval=false if you didn't want to run with fast retrieval. Minor point, doesn't change anything above!