Guillaume Michel

As mentioned above by @aschmahmann, the tradeoff here is to balance the churn rate vs the network size. It is important to have a large number of nodes participating in...

> Can be measured data used to answer question if greater then default 1 day DHT entry lifetime will help? @hsn10 what do you mean?

> 13 % online would mean a 1/8th chance that the peer I'm asking will ever respond? That sounds like a big improvement opportunity thinking Not exactly. The plot you...

> @guillaumemichel DHT entry times out after 1 day and client has to submit it again, This is causing problems where client can't announce all its DHT keys within 24...

We got more insights on this 1s timeout from the [Effectiveness of Bitswap Discovery Process](https://github.com/guillaumemichel/network-measurements-rfm16/blob/master/results/rfm16-bitswap-discovery-effectiveness.md) study. I am fully in favor of setting the default value of `ProviderSearchDelay` from 1s...

We measured that currently 93.65% are successful within the first second after starting Bitswap, implying that only 6.35% of the request make it to the DHT. Starting the DHT concurrently...

An easy intermediate solution would be setting the `ProviderSearchDelay` to 200 ms for instance. In $74.74\\%$ of Bitswap requests, the content is fetched in 200 ms (for our experiment setting,...

> Also, can someone confirm that we have a metric in Kubo that will make it clear what proportion of CIDs are satisfied with Bitswap discovery vs. DHT vs. IPNI....

> Proposal: run tests again and look at TTFB next to CPU and Bandwidth utilization. > > - Test [ProviderSearchDelay](https://github.com/ipfs/kubo/blob/master/docs/config.md#internalbitswapprovidersearchdelay)=1s, 500ms, [200ms, 100ms, 50ms, 20ms], 0s with: > - kubo...

@lidel @ajnavarro Would it be easy to set a different Provider Delay for the DHT and for the Indexers? This would allow us to set the Provider Delay to 0...