A lot of GET_REPAIR and PUT_REPAIR

Hello everybody. I have had a lot or almost only GET_REPAIR and PUT_REPAIR traffic for exactly 3 days now. To be precise since the upgrade to 1.4.2. After the upgrade I switched off my nodes because I thought something had gone wrong :open_mouth: but then I saw that this is the case on all my nodes.

What I also notice is the word “piecedeleter” and that I get a lot of GET_AUDIT.

I found 2 topics here, but find the permanent repair traffic a bit strange and still prefer to ask before I experience a nasty surprise. Audit score is 1000 everywhere.

Or is Storj testing again?

Here is the log of the last 3 hours.

Why do you find it strange? It’s a type of traffic (upload/download/repair) As long as you are not failing audits you are fine.

That is normal.

1 Like

I think he is considering as strange that there is so much repair traffic. And also not much regular traffic.
Maybe I am wrong but repair traffic means rebuilding of missing pieces, right? If there is so much piece rebuilding activity, then the question is, why are there so many pieces getting lost?

1 Like

I usually only had very little repair traffic.
And I’ve never seen piecedeleter before so I was unsettled.

I don’t think there has been an increase in repair and audit traffic at all. It just used to be drowned out by other test traffic. With the test uploads gone for now they stand out more. Why there is so much of it could have many reasons. I think Storj raised the repair threshold quite a bit from initial settings over the past. They probably just want to test this thoroughly and lower it only very carefully. While node churn is apparently quite low, there still needs to be a lot of repair when enough nodes leave. Suspension could also have quite a bit to do with it. Node suspension may be happening more right now due to the database locks. Suspended nodes have their pieces marked as unsafe, which could lead to repair.

Either way, repair logs on your node simply indicate your node is helping out with repair because other nodes went offline/suspended/disqualified. You either make money from the download or get more data stored from the uploads. So it’s actually good for you either way.

piecedeleter showed up since the delete queue was implemented. I think this log line used to just be a piecestore line, but was now moved as it’s a separate process. So just the new way it works, nothing to worry about.

3 Likes

Seeing a bit of a bump but nothing too crazy.

My guess is that the people who are unsatisfied with the payouts are dropping off and the network is backfilling their pieces.

It is my impression that there is way more repair traffic recently. This would correspond with the increasing SNOs dropping out (node suspension, disqualified, unsatisfied).

Impressions aren’t very useful…

April:
image

May (so far, until the 27th):
image

It is my DATA that there isn’t any more repair traffic. And this is despite my node holding more data this month than it did last month.

1 Like

My node is at almost 3.5x upload repair in May than in April. Download repair is around same level.

Hi
I find it strange as well.
Can someone please explain in more details what is the exact meaning of ““Action”: “PUT”” and ““Action”: “PUT_REPAIR””. I started a new node recently and it gets data really slow. However, my log file is full of messages like the ones above. So I am wondering if it works as it should be or I misconfigured it. Here are few screenshots:


image

BR,

Niki

If you’re seeing those messages, it works. PUT_REPAIR is just data that is repaired from other nodes and now stored on yours. It didn’t repair anything on your node, it repaired a file on the network and stored a piece of the repaired file on your node. This is normal network behavior. Data is constantly monitored and repaired when needed.

2 Likes

OK but by repaired you mean that I am receiving pieces of data right? Then how come I have only 15GB for more than 10days? That is extremelyslow compared to my first node, which is 2TB and It got full in like 3 or 4 months. At this rate after 100days for example I will have less than 150GB. My rogh calculations show that the rate is about 10% of the rate that was on my 1st node. That is why I am a bit worried if I messed sometinhg wrong, while setting up the 2nd node.

Traffic isn’t constant, it’s kind of slow right now. The piece size is mentioned in the log, you can calculate yourself how it is possible.

Yes, PUT_REPAIR means you are receiving data. GET_REPAIR means data is downloaded for repair to other nodes (because other nodes lost pieces of segments you still have pieces for).

So this should be Egres or Ingres?

Ingress = PUT(_REPAIR) = upload = Pieces uploaded by a customer (or repair worker) to your node
Egress = GET(_REPAIR/_AUDIT) = download = Pieces downloaded by a customer (or repair worker / audit) from your node

2 Likes

Thank you very much for that information. Which of the two brings more money? Or both are equal?

Ingress brings data to your node. You don’t get paid for the transfer, but you do get paid for the time you store that data. $1.50 per TBm (TB stored for a month)

Egress is paid $20 per TB for normal egress $10 per TB for repair and audit. Of course you need to store data in order for it to be downloaded.

So in short, ingress leads to long term income, egress leads to income right now.

4 Likes

Thank you again for the provided detailed information! :slight_smile: