car-scope legacy parameter is no longer sent on http retrievals and the daemon will ignore it; dag-scope is used everywhere now anyway
502 error from the daemon means "no candidates from indexer" if you're paying attention to response codes
There's some new bitswap concurrency logic that may be worth tuning - old behaviour set a per-retrieval max concurrency for fetching blocks of 6 (i.e. attempt to fetch that many blocks in parallel at a time, max). The new behaviour does a per-retrieval and a per-instance concurrency that you can juggle. The defaults are 32 per instance and 12 per retrieval. Potentially the per-instance number can be cranked right up if L1 nodes are expected to have large pipes and be able to handle it. --bitswap-concurrency sets the per-instance and --bitswap-concurrency-per-retrieval sets the per-retrieval. LASSIE_BITSWAP_CONCURRENCY and LASSIE_BITSWAP_CONCURRENCY_PER_RETRIEVAL are their environment variable equivalents. Perhaps a larger LASSIE_BITSWAP_CONCURRENCY would be good in here?
Bitswap peer tracking has finally landed and our events database is set up to receive this — we get a per-peer "retrieval attempt" recorded for bitswap retrievals, so we can start to get insight into who's providing bitswap blocks, including what share Filecoin providers are providing.
The last item is of slight concern, whether our events database is happy to receive as much data as we may get. I don't think we have any insight into how many peers, on average, we're using per retrieval. If it's a lot of peers then it's a lot more "attempts" to be recording! So I think it would be wise when this is deployed if I'm around (or @hannahhoward instead) to just make sure that (a) the data is going in and (b) that the volume isn't too crazy.
hannahhoward
commented
8 months ago
Major changes impacting Saturn as per https://github.com/filecoin-project/lassie/releases/tag/v0.18.0 and https://github.com/filecoin-project/lassie/releases/tag/v0.19.0
car-scopelegacy parameter is no longer sent on http retrievals and the daemon will ignore it;dag-scopeis used everywhere now anyway502error from the daemon means "no candidates from indexer" if you're paying attention to response codes6(i.e. attempt to fetch that many blocks in parallel at a time, max). The new behaviour does a per-retrieval and a per-instance concurrency that you can juggle. The defaults are32per instance and12per retrieval. Potentially the per-instance number can be cranked right up if L1 nodes are expected to have large pipes and be able to handle it.--bitswap-concurrencysets the per-instance and--bitswap-concurrency-per-retrievalsets the per-retrieval.LASSIE_BITSWAP_CONCURRENCYandLASSIE_BITSWAP_CONCURRENCY_PER_RETRIEVALare their environment variable equivalents. Perhaps a largerLASSIE_BITSWAP_CONCURRENCYwould be good in here?The last item is of slight concern, whether our events database is happy to receive as much data as we may get. I don't think we have any insight into how many peers, on average, we're using per retrieval. If it's a lot of peers then it's a lot more "attempts" to be recording! So I think it would be wise when this is deployed if I'm around (or @hannahhoward instead) to just make sure that (a) the data is going in and (b) that the volume isn't too crazy.