Continuous piece download attempt saturating bandwidth

This isn’t my idea so I’m not that invested in it: but the satellites do tell the clients which nodes to connect to. Imagine if satellites always sent over their 80-110 nodes… at say one node IP every 2 seconds… sorted from slowest to fastest. For large transfers it may take the client a couple minutes to even see the IPs of the fastest SNOs… and in the mean time they’ve been exchanging data with the slow ones. For small transfers they’d complete before even hearing about the fastest options.

The end result would be clients that would eventually still hear about all 80-110 SNOs, so you’d maintain availability guarantees… but their average transfer speeds would be slower because of the artificial satellite bias to tell them about slow nodes first.

I think that would be a horrible idea… and as a client I’d never pay Storj for such a service. But I believe satellites could impact client transfer speeds: simply by delaying those clients from knowing what their faster options are.

You’ll have to scroll up a bit: Toyoo has been trying to explain why to me. In their example link and comment (“increasing the number of download requests that node receives past saturation of bandwidth will start decreasing the number of downloads completed, potentially to zero”) - it sounds like a concern that slow nodes can get into a state where they win few/zero transfer races? So maybe wants Storj to make technical changes so they’d win more in high-traffic situations (at the expense of client speeds, and faster-SNO earnings).

Welfare for slow SNOs?

I think the current “race” system works well, and benefits the clients who are ultimately paying for it all. And if you have a node with poor performance… you should expect to earn less with it.

1 Like