Compared with an 8 core Xeon with 16GB RAM and 7200rpm drives under a 100/100 connection…believe me, Raspberry is slow every days
But yeah, it´s more than decent I have 2 myself on SNO´s.
With an Async Internet Connection you cant get the full Download if you are full uploading. As mention above StorJ is now testing the Upload from the Nodes. I have 20Mbit Uploadrate at the moment, that mean i cant get the full download from my provider. I the that´s the problem here…
I think I might messed up @nerdatwork
As the backup/restore operation takes quite some time (4 days and counting) I thought about moving temporarily the Pi node to Synology while the restore is running.
The issue is that I accidentaly added an extra folder on my run command with the correct identity.
When it started to run, it was not able to find at least 3 pieces with GET command outputting “file does not exist”.
Immediately stopped it and abort it and I´ll just wait for the restore operation to finish.
My question is:
Can my node be disqualified for this?
If it helps, node ID is: 12aXMiwL2FdBUyR5uqH1mKuMvPmmKvtXQrdryKpgA7ezfQATjcq
Only if this is a very new node without any successful audits. If this node already had a good audit reputation 3 missed audits will not harm its reputation too much. You can use the earnings calculator to see your audit score even when the node is not running. Or use the dashboard api when it’s back up and running. But I think you should be fine.
On the contrary, this happened on my oldest node, up and running since May 2009.
Just waiting for the restore to finish to fire it up again.
Thank you for your feedback.
One question please:
I had backup all the data on my NTFS drive.
Formatted to EXT4
Restoring all the data, same structure.
I won’t have any issues with the DBs with the EXT4 format right?
Sorry @Alexey, meaning I won’t have any issue right?
Simply backup identity and data, format, restore with the same structure and fire it up using the same docker run command as used to right?
Just making sure I don’t miss anything…
Between backup, format e restore, my oldest node is offline for 6 days and I’m afraid to be disqualified. I want to make it online asap. Hopefully tomorrow.
Status update @BrightSilence:
Node is up and running after 6 days of restoring 1.8TB data to a (now) EXT4 drive
After a few monitoring, EXT4 did not change much the performance regarding NTFS on my Pi node.
It was just not enough bandwidth (40/10). Upgrading to 100/30 tomorrow.
Btw, tested wondershaper on connection “docker0” and yes, works like a charm
Nice! I wasn’t expecting the file system change to be much of a difference, but EXT4 is the better option either way on Linux so it doesn’t hurt to make the switch. Glad to hear wondershaper is doing the trick for you. But the biggest bump will obviously be the upgrade tomorrow! I hope that’ll get you a nice boost in traffic as well as a better internet experience at home.
Status update and final:
Got my Internet upgrade done from 40/10 to 120/40 final speeds.
Huge performance increase on the RPI 3B+!!!
“Context cancelled” and “Connection reset by peer” errors are now rare, and no more network clogged
Download sucess rate went from 30 to 54% in 12 hours…and rising…upload in on 97%
Just to make sure and one question please:
In the node logs, when we see “Downloaded” means that a piece was actually uploaded from the node to the internet correct?
And vice-versa, when it says “Uploaded” actually means the node downloaded a piece correct?
Assuming yes:
“Downloaded” on the node actually means upload traffic and “Uploaded” actually means download traffic, correct?
Congrats, that’s very good news! Sounds like your upgrade might indeed be paid for by Storj.
Terminology in the logs for the entire storj network is always from the perspective of a customer. So if a customer downloads pieces from your node, the uplink log, satellite log and storagenode log will all refer to that transfer as a download. It’s a little confusing at first, but it makes a lot of sense if you’re looking at it from a network perspective. This is why when speaking of node traffic the terms upload and download aren’t used, but rather ingress and egress, when speaking of the perspective of the node itself.