Graceful Exit (log inspection)

This is the direction I would like to continue our conversation.

Yes and No. I have already stated that I would love to fix the software so that it can deal even with bad infrastrukture.
On the other end I don’t think we have to fix all of it. Let’s say the bad infrastructure also impacts the customer user experience. In that case we should set the right incentives. In fact I have a cheap onboard network card and I don’t know what it can handle. I am willing to plug in a better network adapter if that is needed. I don’t expect the software to solve all of my problems for me. Let’s meet somewhere in the middle. Fix the issues on the software side that we can fix but also accept that this will not help everyone.

Yea go for it. I do expect a different error ratio. You will see a lot of these errors again but thanks to the 5 retries graceful exit will still be successful. Graceful exit will fail if you have a higher then normal number of connection issues and yes they are connected to the host or to the host network. The storj network will give you a baseline of errors. If you end up with a higher error rate the question is why and the answer can’t be because of the storj network. The baseline of errors is the same for all of us.

I don’t think you have to proof anything. I appreciate your input even if it turns out that your proof might be wrong at the end. The data you have collected so far was already helpful for me. You don’t need to fight me / us. I would love to understand what is causing the higher rate of connetion issues. If we can find that out and maybe even implement a workaround that would be awesome.

That is rude? How it comes? Did I say something wrong that gives you the feeling that you have to strike back?


yes, it is interesting and I will follow this path. It will take some time because my logs are scattered, they need to be collected, put into the database and made a request.

That you call bad infrastructure? My servers or cloud servers?
I want to remind you i have 24 node, mostly make GE succesefull. 2 Fail. 3-6 not started for exit. This is about quantity. And about quality. Not about bad infrastructure.

I agree with this in generally. But not in details. StorjLabs suggest always and to all not buy hardware. “RaspberryPi + usb hdd good for storj”
Accordingly, you have to provide a correct GE even for this crap. But in the current implementation of the GE it fails even on the server infrastructure. So I swear in GE. It is irrelevant to your promises.

You must be sure that at least on the correct infrastructure your software works correctly. Doesn’t work now. It is a fact.

1 Like

I know how it works now. There is no need to repeat this through every message. I am so active here because I want to tell you that this approach is bad.
We’re talking about money. When you refuse to pay the money earned to the next SNO, these explanations are not enough. You have to say what exactly this farmer has done bad and prove it with logs in court. And with messages like “reset by peer” or “context deadline” you will be ruined. You will have to prove that all five errors in each piece were due to the error in hard (started from Rpi) (not soft) by a specified SNO. Good luck!

If I were in court I would have won. StorjLabs understand this because i receive all DQ amount. Let’s work together to fix this. Or remake it. Don’t mistake, don’t take me and people like me as haters. You have no more ardent supporters.

1 Like

My goals is exactly the same. If it seemed to you that I was fighting with you or StorjLabs, then my bad English is to blame. I was struggling with only two statements:

  1. That my infrastructure or my servers are source of my DQ
  2. That current DQ algorithm has the right to life.

I didn’t want it to sound rude. I have no such goal.
I would like to say that the more farmers will turn to you with this problem, the more attention you will have to pay to it. In essence, the Stefan Benten satellite was a test. The test, in which the minimum number of SNO are participated, the bulk of them just simply received a HELD without GE and DQ.

Be sure that I treat you personally and Alexei from the support team and many other StorjLabs staff and the entire StorjLabs with great respect and gratitude. I just want the product to become even better, at least to reach the minimum consumer qualities and that I could use it not only as a farmer but also as a client.

But I do not know how to control the harsh tone of the translator. Please write off all the harsh words from me to my bad English. I love you all :slight_smile:

1 Like

Can we restart node in when GE is in process since i have changed the config.yml?

Yes, you can. Just do not extend a downtime more than a few hours.

2 posts were split to a new topic: Graceful Exit. failed to put piece. “error”: “protocol: context canceled; context canceled”