Bitswap Transfer test: Unexpected additional data about beyond-bitswap HOT 5 OPEN

Quick update on this -- I observed this behavior with the Docker containers as well, with network parameters that I believed to be reasonable (tested a few latencies from 10ms to 50ms, and if I recall correctly bandwidth of 150-1024 MiB/s). I do think a
smaller proportion of the data was re-shared (assuming that's what was happening) than outside of the Docker containers. Unfortunately I don't have the plots at the moment and have been modifying my tests/plotting script a fair bit. This may become relevant in my tests again soon, so I'll post another update at that point.

from beyond-bitswap.

So, we do have to cancel a bunch of CIDs but that won't show up here.

We do re-broadcast our wantlist every 30 seconds, IIRC (to deal with a few connect/disconnect race conditions). Maybe we're not processing incoming data fast enough and re-sending want items for things we've already received?

Can you reproduce this with 2 nodes?

from beyond-bitswap.

My suggestion would be to use local:docker instead of local:exec so you can add some latency between the peers. This way we can be sure that the seeders is not clogging "computationally" sending the data.

Also if you don't mind reproducing with 2 nodes or adding more seeders see what happens. My experience with local:docker is that the results end up being pretty noisy because we lack the "network impact".

from beyond-bitswap.

@Stebalien I was able to reproduce with two nodes after doubling the file size:

@adlrocha thanks for the suggestion! I'll try that out and report back -- takes a bit of work to switch to running in Docker, as I'm building off of a local version of go-bitswap with changes to help me gather metrics.

from beyond-bitswap.

On a bit of a hold with the Docker runs, figuring out how to get it working with my local repos: testground/testground#1213 (comment)

from beyond-bitswap.