Repair egress significant, why?

Quite the opposite. Even starting out it doesn’t matter whether an unvetted node gets a repaired piece or a new piece, if it turns out to not be trustworthy it’ll lead to repair either way. The satellite won’t care much if it has to repair the same segment again or a new segment.

That said, you could say that the nodes that still had pieces for the segment that needed repair have already proved to be relatively long term reliable. Selecting a few higher risk nodes in that scenario would actually be safer than selecting higher risk nodes on a new segment where all nodes are selected at random.

There most likely is no difference to the network between having to repair the same file 10 times and having to repair 10 different files once.

1 Like

Yeah you’re probably right.

Thanks for the clarification.
The node’s reputation seems irrelevant at the moment… I wonder if it ever will…

Irrelevant for node selection, yes. But not for disqualification. However, there seems to currently be no difference between a score of 61 vs 100. Drop below 60 though and your node is disqualified/suspended depending on which score is below 60.

And, as it seems, the length of time that SN provides a service for the Tardigrade network does not matter to the reputation, and this is what I expected :frowning:
And now I know it is as it is

Well the longer you are on the network the more data you have. Additionally the more repair egress you see. Add to that that in the first 9 months significant amounts are held back and I would argue there are plenty of incentives to run long term reliable nodes.

1 Like

Not always - see full SN

What use is preferential node selection if your node has no more space left to fill? It can’t be selected to begin with if it’s full.

Preferentially for the exit :slight_smile:

Do you mean egress? While that’s possible, it’s probably not ideal. Random selection for egress leads to more equal load balancing and better performance for the customers. It could also lead to some newer nodes never seeing any egress and leaving before they actually get a chance to make some money.

You’d still see some benefit of more repair egress over time even if your node is full.

Just use your profit to buy another HDD. :wink:
That’s why I did twice already. Storj generates enough income that I can make sure my nodes are never full.

I think most of the questions are already answered. If not just let me know if I can help.

I would like to add a few information.

  1. At the moment we trigger repair already at 52 pieces instead of 35. This doubles the repair download. Long term you should expect less repair downloads. It should not change the repair upload. We repair the file twice as much but we need to replace less pieces.
    The reason for this higher repair threshold is safety. We haven’t lost a single file even with some bugs in place. We want to be very careful here.
  2. For the past few month the repair queue was growing faster then we could drain it. This is not a big deal because the lowest health on the queue was maybe 50 or so. Long term it would mean that the minimum health will slowly decrease and in some months we might lose files. For that reason we scaled up repair workers. The best way to avoid scaling issues is to target for an empty queue. The side effect of that decision is that you currently get more repair uploads and downloads than you normaly would get. As soon as the queue is empty the repair uploads and downloads should drop significant. Please don’t start estimating your repair traffic. This is a short term event while we draining the repair queue.

Ahh that’s good info to have! Thanks. Is this trusted delegated repair in action?

Thanks @littleskunk good Info!

No. The idea behind trusted delegated repair is that we have a repair worker that asks the satellite for work and reports back the results. We have to trust the repair worker to work as designed but if the machine gets compromised it would have only limited potential to harm us and over time we could make this more and more untrusted to the point that even a storage node could be a repair worker.

Currently running is the old satellite repair worker running on a remote machine with direct access to the database. This comes with higher risks then trusted delegated repair. I hope it is only a short term solution and we will replace it with trusted delegated repair at some point.


Got it, I assume trusted delegated repair will make it easier to scale these solutions as well and also make them a lot cheaper by hosting them elsewhere. But good to see you’re able to scale up without it too. As for nodes doing repair, sign me up when the time comes! :wink:


Is node churn getting worse?

Repair ingress is getting quite high on my nodes, many days as high or higher than normal traffic. I am very happy with my profits and welcome this data to my node. A high node churn is concerning for the network though, it seems there are many people who expect to get very rich very quickly or are disappointed at low income in the first couple months.

Ah, I didn’t notice there was already an existing discussion for this topic. Thanks

I can’t close my own threads, if someone with a higher trust level sees this please close this to avoid fragmenting discussion

35 always felt pretty dangerous to me, but I guess it’s fine statistically speaking…

Thanks for these detailed explanations @littleskunk :+1:

Me too! :raised_hand: :wink:
But I guess if it were to be implemented on SNO’s side, all SNOs would just upgrade to a new version one day that includes this new system, right?