Looks like today be unvetted node be much better than vetted.
Here is 2 nodes that share one ip, as they got vetted traffic dropped dramatically
Me, too, since months.
This has been the case since they sped up the vetting process. Unvetted nodes have become a pretty small pool. Perhaps some tuning of how many pieces end up on unvetted nodes is warranted. Right now it’s 5% of pieces, but technically a single piece for each upload should be plenty. This is not a good thing to keep like this as it might incentivize people to spin up many new nodes.
4 Likes
Thank you for the excellent observations, everybody. I have now ticketed this as Need to retune % of data going to unvetted nodes · Issue #6011 · storj/storj · GitHub and we should have it fixed soon!
6 Likes
That was 3 weeks ago… 
1 Like
Did you see this comment on the GitHub issue?
thepaul commented 3 weeks ago
Thinking more about the multiplicative effect where unvetted nodes share a last_net with vetted nodes. The last_net for the unvetted nodes effectively gets counted as a separate network from the last_net of the vetted nodes, which is why it can make such a difference.
We might need to do a bigger refactor of node selection code in order to mitigate that effect, so it doesn’t become an incentive to keep lots of nodes unvetted.
I’m guessing it may take a little longer. I posted a suggestion on the issue as well at the time.
ReneSmeekes commented 3 weeks ago
Suggestion: Create a satellite setting to set the % of normal node ingress an unvetted node should get. Calculate the number of pieces to go to unvetted nodes by: (nUnvettedNodes / nTotalNodes) * unvettedTraffic% * nPiecesToSelect
This won’t usually be a whole number. In fact, in the future this will likely be below 1. To resolve that, round that number down and generate a random number between 0 and 1. If that number is below the remainder, add 1 to the rounded down number of unvetted nodes to select.
That suggestion may not be too complicated to implement, but they might go a different direction. Either way, I guess it might take a little longer if they intend to do more than just change a setting. Though in my opinion, they should do both. Change the setting now, implement a more comprehensive fix later.
1 Like
Sure.
Agree, would have expected a short feedback / update on that.
this issue is already queued with high priority in the next up sprint.
3 Likes
