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.
Earnings calculator (Update 2020-09-15: v9.4.0 - Uptime is back! Now compatible with v1.12+ and more verbose warnings)
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.
Awesome! In the mean time I was trying to find out why we have different behavior. It looks like different python versions use different output types when using division. And for some reason my python 3.7 behaves as if it’s 2.x… Anyway, I found the proper way to do it and cleaned up some extra code. If you would be so kind to test one more script?
Awesome, you’ve been a great help! New release is now live on Github!
Edit: I deleted previous posts with code that didn’t work to prevent others from using bad fixes.
v8.0.1 - Layout fix
- Fixed a layout issue when displaying vetting progress on some python versions (Thanks @schnutzie helping me test)
As if the script would indicate in which month the SN is active … it would be extra
I’m not sure what you meant to say here. If this was a request, please specify.