ldeffenb

And adding another log to the mix shows something even more strange. First note that the "new_size" definitely seems to be tracking the total reserve size, not the size within...

And yet another iteration with additional logs provided in https://github.com/ldeffenb/bee/tree/d5c2646808030e52f4578c369b5862e8739686b8 It seems like there should be one and only one bit of code controlling reserve radius increase AND decrease and...

Since the batch evictor has been modified to only remove the required number of chunks rather than the entire batch, the oscillation seems to have been fixed. At least, the...

It also seems kind of pointless for a node that is freshly pullsyncing to be offering all of the "new" chunks to the other peers, only to have them (as...

And no, the host is not CPU, Disk, Memory, nor network bandwidth bound.

Every node in the testnet swarm should have all of the chunks, but will the new node ever get the final few? Film at 11. 

It did finally finish and get up to the swarm's reserve level, but that last 15 minutes was agonizing to watch. 

And just to complete the picture, here's the final reserve growth graph. I'm working to fire up another new node and may enhance the logging in the pullsync area to...

I just discovered the bee_puller_synced_chunks of historical vs live, so here are those graphs:  And zooming in on the final 15 minutes shows that they were historical pulls that...

I may understand a bit about the nature of the reserve growth. Bins are pulled in parallel from a single peer, and all peers are started at the same time....