First statement you quoted you made yourself, not a Storj employee. Second statement is not stating anything other than asking you to prove your statement, third quote is from someone who is not a Storj employee.
This was setting up the context for the second quote.
Hmm? Then what is the forum designation for an employee? Not “Storjling?”
At any rate, even if the third quote is not a Storj employee:
- This discussion appears to once again show that SQLite is not reliable enough to be used in this configuration which is (to me) proof enough that other options should be considered.
- I have still never heard any reply to my comment about the
-t 300recommendation. Is it the position of Storj that using
-t 300is required not to corrupt the database?
I’m still baffled by the assertion that SQLite is good enough for production and then we have threads like this that demonstrate quite clearly that it’s way too easy to break.
(Perhaps this needs to be split into another topic.)
Edit: Note that my intention is not to be argumentative or hostile. But I feel like I’m being told two different things: “SQLite is fine” – “tiptoe around SQLite because you might break it.” As an SNO, this does not give me confidence.
The second quote is not claiming any of the things you stated, nor validating your quote above it. We currently do not have special labels to identify the actual Storj employees vs external contractors/forum mods. In any case, the statement “I think executing the script inside different folder is safer” is not making the claims you stated before in your earlier post, besides which this user specifically qualified this as being their own opinion. I think it is not constructive to continue this particular conversation at this point.
Besides, I would like to add that I appreciate the usually very open communication by Storj employees. With this comes that different people can have different opinions and we shouldn’t treat Storj as a giant monolith. I think there is a lot of value to having this differing opinions out in the open, so I for one applaud any apparent contradictions rather than throwing them back in their face.
For me personally, I warn people out of an overabundance of caution stand point. I felt really bad when other SNO’s got their node in trouble as a result of using my scripts. So I take a better safe than sorry approach in my instructions. This should not be taken as a sign that SQLite is not reliable. I think it definitely is when used in the correct context.
Can someone help me interpret how to read the output of the earnings calculator? I don’t understand it. The totals don’t make a lot of sense to me. I really only make $2.84 for the entire month of November? And why does it say -not paid- for so upload and disk usage? Sorry if this sounds like a dumb question. Is there a key to these metrics somewhere?
Yes, you will be paid around $2.84 for November.
Ingress traffic (uploads to your node) aren’t paid because you will already be paid for storing that data. Hence ingress is already good for you. Paying for both would be like paying you double for the same thing.
The bottom 2 items are basically the same thing displayed in different units. They both express how much data you’ve stored throughout the month. I find the GBm unit a bit more clear as that is just how much data was on your node on average throughout the month, but I included the TBh unit as well as that is what the web dashboard shows as well. I could list it as 1.11 USD as well, but than the total wouldn’t match anymore.
That said, if this is your first month, you should keep in mind that new nodes are in vetting phase on each satellite for about a month (until they have at least 100 successful audits on that sattelite). And during that time a node gets about 5% of the traffic it normally would. This is done to gauge whether a node is reliably holding the data it received before the network makes full use of it. This way bad nodes can be rejected before it would lead to massive loss of pieces and lots of costly repair.
I hope that helps.
Hi, thanks for helping me understand this.
I’m still confused though. For October, I supposedly made only $2.00. However, I received quite a bit more than that in Storj tokens. In September I only made $1.45 according to the earnings calculator, but also received a lot more than that in tokens. Could the disparity be explained by the “surge” pricing?
(Aside: for November I’ve only received 0.13359354 Storj so far. Weird.)
The other thing I’m wondering about is how this squares with the earnings estimator located here: https://storj.io/storage-node-estimator/ ? I have a dedicated Storj node, modeled after the nodes that the Storj team used to boostrap the network, directly wired into my router, with symmetric gigabit fiber that has been continuously online since August (or maybe June 2019). Is there a way to make my node more profitable? Are other people making more than me or is this simply par for the course at this point?
November payouts are not done yet. Please hold off with making comparison analyses with last month’s payouts until all satellites have finished getting their payouts done. Thank you. Also, if you are modeling your node hardware after the nodes running on Raspberry pi 3 by Storj team members, I am sure there is other hardware that would give you better performance. However, it is not recommended you run out to buy new hardware just to build another Storj node.
The months you mentioned did indeed see surge payouts. Also keep in mind the escrow being held back in the first 9 months.
As for performance, you might want to look at this thread.
The script used in that thread can be found here.
@BrightSilence I think a simple change to your script would make it safe to use against a database that is open in another container: open the databases as a
file: URI with the
?immutable=1 query string (requires Python 3.4+). From the sqlite open docs:
immutable: The immutable parameter is a boolean query parameter that indicates that the database file is stored on read-only media. When immutable is set, SQLite assumes that the database file cannot be changed, even by a process with higher privilege, and so the database is opened read-only and all locking and change detection is disabled. Caution: Setting the immutable property on a database file that does in fact change can result in incorrect query results and/or SQLITE_CORRUPT errors. See also: SQLITE_IOCAP_IMMUTABLE.
This guarantees that sqlite will not perform any writes to the database (even journal recovery) but it does mean an error could be returned to your script if storagenode makes a concurrent write to the database. The script could capture these errors and retry the query until they succeed.
For an even higher degree of safety, the earnings script could be run from Docker with the storagenode databases provided as a read-only volume (
:ro option to
-v). This way there’s two layers of protection: sqlite in immutable mode, and if there is a sqlite bug even in this mode that tries to write to the database, aufs will reject the write to an overlay filesystem it has configured as read-only.
Obviously erroneous results could still be returned. However, this may be a happy medium between “you have to shut down your storagenode to run this script” and “you don’t shut it down but you could corrupt your database.” No shutdown and no possibility of corruption, but the very slim chance that the results are inaccurate.
Has anyone tried to run this against the windows GUI version? If so, exactly how did you run it?
I haven’t tried it myself, but should work just the same. Stop the node, copy the files, start the node and run the script with the path to the copy of the DB files.
So I will still need to download python, right?
Yes, you still need python
Unfortunately it seems I can no longer edit/update the top post on this topic to add new screenshots and changelog. Anyone know what’s up with that? @jocelyn maybe?
Anyway, there is a nice new release today that offers some additional information about uptime and audit scores, shows you the progress of vetting and a status that displays whether your node is OK or disqualified(DQ). Please note that there is no historical information kept for this data, therefor it is only displayed when looking at the current months data (no month argument used). This update does require you to copy an additional reputation.db file. See changelog below.
I wanted to add a little explanation on the uptime and audit scores. I chose to multiply the actual scores by 1000 for several reasons. The first is that there was limited space in the layout and the original scores between 0 and 1 waste two positions on 0. for every score except a perfect score. I also wanted to keep 3 significant positions in order to give a good indication of how far from perfect the scores exactly are. And last, I didn’t want to display the numbers as a percentage or even suggesting that it’s a percentage by using 100 as the max. The scores added here are not the percentages you see on the web dashboard, but the actual scores used for reputation and disqualification.
Don’t worry, not my actual node data. My node is not disqualified on one sat and in vetting on another. Just messed with some data to show all new features!
v8.0.0 - Reputation update
- Added status to show whether your node is OK or DQ (disqualified)
- Status displays progress of vetting while still in vetting phase
- Added uptime and audit scores (0-1000)
- Code cleanup merged (Thanks @smurfix )
@jocelyn looks like Out of service, not responding from Monday. But all need to rest time to time.
That’s ok, I’m not in a hurry. Luckily the top post already links to the repository which will always have the latest code anyway. And I’m still able to update the title with the latest version. Just not the top post. So now the changelog and screenshots aren’t up to date.
It looks like you can’t edit posts older than a month. I can understand that in most scenarios, it’s just inconventient here. And I don’t want to spam the forum with new topics for every update.
Thanks for your update. The vetting-part is helpful. I have a problem with the layout. I can see all but it is shifted. Ubuntu 18.04.
With the new change it’s the same problem.
It’s not a problem to test your lines.