Node disqualified...WHY?

is that of a such a big difference?

Of course it makes a difference, The faster the internet not so much but the slower the internet yes it makes world of difference. If your on cable/DSL uploading will slow down your download speeds.
This means you will loose more races overall =less data = less profitable

Because your using this internet at the same time right? What is your upload speed?

1 Like

the speed from my provider is 1:1 download:upload
but i am not so sure about internation traffic
i will look for a tester and will see that is the real result
but 50mbps should be plenty

Is your internet Fiber? if not then its not 1:1 you can advertise intenret speeds to being 50/50 less your on fiber internet you wont see 1:1 speeds cause upload will always be using bandwidth from download speeds.

By todays standards 50mbps is pretty slow… I went from having 10gbps internet to 1gbps internet and I can tell you im feeling it, But I have seen 1 of my storagenodes hit 100mbps so we cant say 50mbps is plenty when it comes to data speeds.

1 Like

From my experience it does not matter that much.
My 50/10 node performs about as good as my 100/40 node

Of course the lousy 10mbit upload will become a bottleneck once there is more egress…

1 Like

In my experience 50mbit is usually enough to do ok, latency becomes more important which is often location dependent. Where are your nodes located (country only is fine)?

Might be useful to run this script to see how your nodes are doing on success rates!

That would show if there is an issue with “losing races”.

1 Like

I am in Bulgaria and the nodes are here as well. I think the latency is not bad but I will test once i get some time. Because we have another storm at the moment and my internet totally stopped. I hope they will fix it by tomorrow.

Here is the output of the script:

But as I mentioned I had few bad times. So maybe I should delete the .log file and restart the node and wait 2 3 days for some logs to build up and re-run it. What do you think?

These scores really don’t show any issues. So at least for the period that is covered in these logs, it’s looking fine.

I guess other things would be if you had significant down time in the past. Any down time of more than 4 hours would lead to data loss due to repair in addition to the missed ingress. The earnings estimator assumes perfect online time.

I had an internet outage since Thursday - 4 days. :slight_smile:

i have now deleted the old log file and will run the script after 3 or 4 days and will share here the output

Ahh, that’s annoying. Does that happen a lot?

Every time you are offline for longer than 4 hours you lose about 2-3% of older data due to repair. Of course if it lasts 4 days that percentage goes up further too.

1 Like

well unfortunately 2 times this year :frowning:

Here is a screenshot from 1 day log,I errased it yesterday:

What do you think?
It looks OK but nevertheless it has some failures.

Don’t worry about those failures unless they pop up for audits. Unfortunately some cancelled transfers still pop up as failures from time to time. Everyone has them and they can’t really be avoided. Audits are never cancelled though so critical failures there are really bad. Others are fine and you success rates look great too. These numbers show nothing to worry about.

Great! Thank you! :slight_smile:
and here is the info for my 2nd node:

I will delete the log file here as well and will check again in a couple of days.

Could you search, what the reason for failed GET_REPAIR?

on which node and how ? Should I search for “GET_REPAIR” messages in the .log file?

2021-07-06T16:11:28.567+0300 INFO piecestore download started {Piece ID: PRUTUH7HXNNBYKUNJVFYLFZHCVNLX5NJIM2ZMNIPMH5NXURRQH6A, Satellite ID: 12rfG3sh9NCWiX3ivPjq2HtdLmbqCrvHVEzJubnzFzosMuawymB, Action: GET_REPAIR}
2021-07-06T16:11:28.647+0300 INFO piecestore downloaded {Piece ID: PRUTUH7HXNNBYKUNJVFYLFZHCVNLX5NJIM2ZMNIPMH5NXURRQH6A, Satellite ID: 12rfG3sh9NCWiX3ivPjq2HtdLmbqCrvHVEzJubnzFzosMuawymB, Action: GET_REPAIR}

It should be log entries marked ‘WARN’ or ‘ERROR’ with the GET_AUDIT action.