Counter-intuitive idea: Allow for bandwidth throttling

Hey guys,

I was wondering if we (and by we I mean the community behind coding, AKA not me) would ever consider an option to throttle the amount of bandwidth used during certain hours?
I know it’s counter-intuitive, as you would want your node to be able to up/download as much as possible. But here’s why I ask:
I work for an MSP as the sales manager and a “senior” (read: more mature) tech that looks after dozens of servers for our clients. I’m looking to see if our backup provider can allow us to use Storj as our cloud storage option, and encourage our clients to use it. As part of this, they allow us to use some of their unused space to donate back to the network and thus get a discount on their backup costs per month (provided by us, not Storj - this would be a reseller thing).

The idea is good, except I can guarantee that all our clients aren’t going to want to be using 100% of their bandwidth during business hours (we are in Australia BTW), so for this to work we would need to somehow be able to throttle the Storj node’s bandwidth usage during their business hours. However it can run full throttle late at night, for example. I don’t fully understand the backend, and if that would impact the node’s reputation. Or maybe it wouldn’t be much of an advantage. But if it could be incorporated I would say right off the bat that our MSP could have well over 40TB of unused storage across at least 12 locations, and probably a lot more.

Even just being able to integrate it with a backup solution would be fantastic, since then as a sales man I can encourage the client to buy a NAS or server that can store more thyan they need, to be used for Storj - They get cheaper monthly backup costs, Storj gets another node that’s on 24/7 and we (hopefully) get the storj. Everyone wins!

Let me know if I didn’t explain myself very well - I might be a sales manager, doesn’t mean i’m good at selling ideas though :slight_smile:

You can use traffic shaping to, well, limit the traffic. There is not really a need to include that in the node software I think.

1 Like

There are lots of tools available to do this on a per process basis without the node software itself supporting it. But I’d argue that lowering the concurrency is probably the better way to do this. Since the pieces are very small, setting the concurrency to a low value effectively limits bandwidth but will have a much smaller impact on node reputation as when transfers do happen, they are still speedy. I’d start there and if it still goes over acceptable limits use a bandwidth shaping solution like @Pentium100 already mentioned.


Hi Colleagues,
I would like also pay attention to your router’s, most of routers have traffic shapers and prioritization out of box. Check your routers for this functions, may be you already have it…

1 Like

Sorry, I should have made it clearer that I’m not going to do this until we are out of alpha, and even then I’d want to see it very stable since it’s literally be on production networks - any bugs cant affect our clients…
I was talking well down the line when gui comes out. But I appreciate the input!

1 Like