The idea is to give power to the SNO to configure availability preferences of his node based on how own preferences. E.g. limit bandwidth at certain times of the day, or deactivate the node completely on schedule (maybe the user requires high performance on his storage or high bandwidth), or set daily/hourly limits for egress/ingress. This would of course have an impact on the node’s overall rating and rewards adjusted accordingly based on that. The less restrictions (i.e 24x7 availability with the highest performance possible) the better the reward is. Realistically speaking many potential SNOs would decide not to join the network and host a node because of the lack of control on their IO and bandwidth.
Also a manual button to temporarily deactivate the node from the dashboard (maintenance mode, let’s say we want to update the storage firmware) would be nice.
Your node could be offline for 288 hours before suspension, then you would have a week to fix the problem. After you fixed the problem your node would be on review for the next 30 days. If node would be still suspended after 30 days it will be disqualifed.
To recover online score the node should be online for the next 30 days.
Suspension mean that your node will not receive a traffic. Since your node offline or suspended, all its pieces considered as unhealthy and if the minimum available pieces would drop below threshold, the repair job will be triggered and it will repair missed pieces then places them to other nodes. So, as soon as you bring your node online, the garbage collector will remove these pieces from your node.
So, the offline is penalized with reducing ingress and removing pieces from your node.
Thanks Alexey for the warm welcome and fast response!
I’m not suggesting to bring bandwidth allocation limits back as default, but to leave this choice to the operator. As operator, while I would like to maximize returns, I would also like to control when and how I offer storage. Those rules for disqualification are a nice feature, however there could be a bit more elaborated rating based on operator defined policies (e.g. maximum rating if no restrictions, max bandwidth and 24x7), however a reduced rating if implemented some bandwidth restrictions, either permanently or temporarily, and the same for availability (maybe I would like to switch off my node at certain times, even if it penalizes). Goal is of course to be available as much as possible and maximize returns, but there might be good reasons to instruct the node to shutdown during some periods, or allocate bandwidth restriction on a cron schedule.
Based on your answer above, the maintenance mode does not make sense, indeed But my first feeling setting this up is that I was going to give away my storage and my bandwidth, and could impact me on times where I need more throughput and the only solution is to switch off the node by killing manually a docker container. In general, the main things we share as hosts is bandwidth and storage, so a bit more control over those is what I miss…
Storj nodes usually use few bandwidth on average these days. So unless you’re on a weak VDSL connection, it would probably not cause any issue with your Internet access.
Here is an example at my place (YMMV) on the 1st of Feb:
I had 43GB of Egress and 14GB of Ingress.
That’s an average of ~500kB/s (4Mbit/s) for upload, and ~160kB/s (1.3Mbit/s) for download. (upload & download terms here are from my point of view as an SNO - not to be confused with terms download/upload that are usually used from users point of view in this forum)
Note: I’m storing a total of 5.5TB.
Of course, things might speed up at some point, especially if load tests happen (it did in the past and bandwidth usage was way crazier than that) but it’s pretty quiet and stable these days.
In fact things are even slower since 4-5 days ago…
I like the bandwith restriction idea. Currently I work from home and even if the node traffic normaly is low if it spike during a videoconference can make me crazy. So for me a setting for capping the bandwith can be really useful, of course the minimum available required by the TOS must be respected
The point is not being able to do that, there is always a way around using external tools. It is more about the operator having no control through the dashboard over the operated node (not even a restart node). Being able to control the very basic aspects of the node, such as the maximum throughput that it should produce (or even include some DSCP classification in there) would be nice. It is not always the recommended way to give this responsibility to the router, especially for smaller/home setups. Also using third party tools /os Tools to cover for basic things that the application does not support is not convenient. 8f people need to do it anyway, why not provide an easy, straight forward and supported way. Even if it goes against ToS, it improves the node usability. There could be ways to ensure the quality of the service, by using some sort of performance score, auditing things like throughput, delay, packet loss… You could easily ensure that nodes that are fully available and responding at faster rates get selected more often…
It is designed to do not limit a bandwidth, otherwise your node would be always in the cut of long tail - slowest nodes will be dropped by the customer in favor of more faster nodes.
I get that, but is that a bad thing? I know it would introduce polarization but the system should have ways to handle that. Being on the cut of long tail slowest nodes would just hint that the community of node operators are providing better hardware and connection throughput than me and hence I should invest in upgrading my hardware / internet connection to be more competitive. However it should not mean that I am always excluded… how does the system identify better nodes today? Is it equal opportunity? Maybe setting a minimum load distribution coefficient on the satellites can help avoid too much polarization, but you would definitely want to leverage the better nodes (based on performance score) if they are enough in numbers. I would imagine starting with a more permissive load distribution to guarantee reasonable participation (maximum load distribution would mean equal opportunity) and make it more demanding as the network grows (controlled polarization towards better nodes increases performance while still guaranteeing decentralization and participation for the slow nodes).
It’s already evenly distributed - the list of nodes is formed randomly - one node from the each /24 subnet of public IPs, this list is given to the customer and the customer will decide, which of them will be used (the customer requests 110 nodes from the satellite and stops uploads when the first 80 are finished).
When it downloads data from the network, it requests 39 nodes and stops downloading, when the first 29 are finished.
So, the initial selection is random, widely spread over globe
But customer will have a deal only with fastest ones.
But my first feeling setting this up is that I was going to give away my storage and my bandwidth, and could impact me on times where I need more throughput and the only solution is to switch off the node by killing manually a docker container. In general, the main things we share as hosts is bandwidth and storage, so a bit more control over those is what I miss…