Hi all, I’m new to this so apologies if this has been answered before - I did a search on the forums but couldn’t find much advice so far.
I’m planning to set up a node on a Raspberry Pi 4 or a Linux VM. It will be in an environment with 100Mbs symmetric internet connection, however I will only be able to use this fully for 12hrs per day. The other 12 hours will have to be limited perhaps to 10-20Mbs.
Can this scheduled throttling of bandwidth usage be managed within Linux (any recommended methods please?) and/or Storj node configuration parameters?
Also, will this daily changing of available bandwidth for use by my node be acceptable by StorJ and what affect this would have on payouts? I.e. would my node suffer reputation loss and significant reduced payouts over and above that would expect because of the bandwidth throttling?
Yes. The standard solution provided by the Linux kernel is tc.
Yes, this should be fine. You might see more failed uploads/downloads and lower total egress during the throttled period, so there may be a resulting reduction in generated revenue.
This is very unlikely as long as your node is passing audits.
I guess it depends what reduction you would expect due to the throttling. You will have lower ingress and egress potential. Egress directly earns you revenue. Ingress contributes to your amount of data stored, which you are both paid directly on and is a potential generator of egress revenue (you can’t upload data that you don’t have).
If you aren’t careful to set up the tc settings particularly around the allowed sustained vs burst rate, there can be contention for ingress/egress traffic that can cause you to lose more upload/download races. So the impact can be two-fold: lower revenue ceiling, but that drops lower when you are trying to service multiple upload/download requests simultaneously and this causes you to service those requests slower than other nodes.
Proper burst configuration in tc mitigates this. Effectively you can set it accrue burst tokens during long periods of inactivity (sustained traffic below the limit) which it can use to burst (potentially up to the full 100Mbps) for very short periods. This keeps the average rate over a long period of time below your limit but still allows “violation” of the limit in the short-term.
Of course, if your node constantly wants to exceed the limit then it will never accrue any burst tokens and it will simply sustain the limit for the entire period.
Great - many thanks for your detailed response! I’ll investigate tc and the other aspects you mention - good to know, thank you.