Just a fair warning. There is an open PR to remove bandwidth caps from the codebase. I expect that change to get merged and deployed within the next 2 weeks. The storage node will ignore any bandwidth cap and you might end up exceeding the bandwidth cap of your ISP.
Reducing the allocated space should help to reduce the traffic. Another option would be graceful exit.
If you’re interested in more details, we posted more about this decision here: https://storj.io/blog/2020/02/maximizing-bandwidth-earnings-for-storage-node-operators/
…Or restricting the host Ethernet interface bandwidth via the host OS.
Short term that might work. I would expect that you get DQed for that. Please also take a look at this: Design Draft: Storage Node "Suspended" State - #14 by moby
I never reached not even 50% of it, not even last month, which was the best so far.
Bring it on 
I have another concern for DQ: I have two ISP, main - 1Gbit/1Gbit and backup (for failover) 20/20Mbit.
When my main ISP will down, my router will switch to backup ISP (and storage node too).
So, is it can trigger DQ for me?
No, why would it trigger DQ if you node remains active?
Because switching to backup ISP (from 1Gbit to 20Mbit) trigger bandwidth limitation for a few min. to a few days, depending on the size of the problem that the main ISP will have.
you might just lose most upload/download races but since you still respond correctly that should be no problem.
I’m pretty sure littleskunk was referring to if you reduce bandwidth to near 0 or at the least below the minimum requirements. I’m sure you’re fine as long as you’re above the minimum requirements.
you also can modify not bandwidth but speed. it can be calculated with band cap. and just put speed limit for this connection. also some better routers can limit speed with band cap automaticly.
Thanks, @kevink @BrightSilence !
I think I misunderstand words about “restricting on the interface”. I just care about uptime and data availability for customers, lose some races for upload/download is much better for me than offline on disaster situation, and I would not want to get DQ for it
Because 20/20 is below the currently allowed minimum of 25mbit/s download
I guess it technically is. But I know for a fact that at least currently that won’t be an issue. Lets say I know of someone who runs a node on an even slower connection, without many issues.
Just curious, do you know how long it takes for satellites DNS cache to expire? What’s your TTL?
I also have two ISPs, but they are both active (inbound) all the time and the outbound failover is done manually atm.
I believe satellites do a new DNS lookup when they can’t find the node at the cached address. So it works a little different than traditional DNS cache.
I think it works exactly the same, but I’m curios how /u/Odmin is doing it.
I too have multiple ISPs; You gotta setup Dynamic DNS on your node or router to take advantage of failover. Otherwise it’ll continue to say “Hey I’m at this IP/port!”. I also use cloudflare(dns-only), TTL is set to Auto and it seems to work fine enough for me at the moment.
Added Edit: I also don’t think DynamicDNS is meant for a load balanced gateway, at least for the case of the machines I have Storj nodes installed it’d only make sense to reply from the same external IP/gateway as a request is made from, as some server and networking software will see this as a request made from a proxy consisting of multiple IPs because of the whole responding to another IPs request thing.
Sorry, I miss your qustion.
I using my own DDNS service (you can use any public) TTL=300s. Router is take care about manage ISP and correct reply to proper interface.
Yep, the same for me. I using DDNS client on the application side (on storage node). Router only take care about monitoring the health of ISP’s and switching uplink on disaster situation.
