Earnings calculator (Update 2019-10-13: v7.0.1)

I thought I already had a topic for this earnings calculator, but I guess not. I made this calculator as an extension of the dashboard functionality already provided by storj.

storj_earnings

Earnings calculation script for Storj V3 storagenodes

Prerequisites

Python is required to run this script.

This script was tested on Windows 10 and Linux, with Python 2.7 and 3.7. Other OS’s and versions will likely also work.

Warning

Especially if you are running on Windows or MacOS, stop the node, copy the info.db to a different location and run the script from there. Running the script on these OS’s while the node is using it could lead to corruption of the database, which will kill the node. This approach is best practice on Linux as well.

Usage

Earnings for current month:

python earnings.py /path/to/storj/data

Note: If you omit the path it will look in the current working directory.

Earnings for previous months:

python earnings.py /path/to/storj/data 2019-05

Screenshot

image

Get latest version

Changelog

v7.0.1 - Cleanup output

  • Remove debug print lines
  • Made the script compatible with the split up sqlite3 databases
  • Changed readme to reflect the 3 databases required for the script to work

v6.1.0 - Historic storage data

  • Storage information for historic months is now also available starting with September 2019
  • Small change in terminology for used storage to align with planned changes on the SNOboard (GBm instead of GB/Month, which was actually mathematically the wrong unit anyway)
  • USD amount is now shown on the Disk Average Month line

v6.0.0 - Big refactor with several updates

  • No more estimates for disk usage, it now uses the nodes own numbers
  • Switched Disk Average to usage so far based on Bh (Bytes*hour)
  • Added Bh line and switched the total line to Bh as well
  • USD calculation for disk usage now doesn’t assume usage will stay the same for the rest of the month and displays USD based on usage until now. Just like for bandwidth only USD made until now is displayed. This results in this version displaying a lower number than the previous version as future income is not counted yet.
  • Known satellites are now mentioned by name
  • Visual tweaks
8 Likes

This version runs FAST!

Yep, since they introduced bandwidth rollups in the db there is much less data to go through. I wish I could claim that improvement, but that’s all storjlabs. I just changed the script to use the new tables.

Thank you for this helpful tool!

Just a thought: it would be even easier if the tool handled itself all the preparation:

  • stop the node
  • copy the info.db in a temporary directory
  • run the calculator algorithm
  • delete the file
  • restart the node

Why do you think?

To be honest, I think it’s probably safe to run it on a live db on linux. That’s how I’ve been using it for months now. I just felt really bad when people using my script ended up with a corrupted database, so I didn’t want people to take the risk. On windows and macos you really shouldn’t do that though. I could make the script to do everything you mentioned, but it’s kind of trivial to make a script for it yourself and everyone is using different paths and container names.

For linux systems it’d be something like this. This may even work as a powershell script as well, since powershell adopted a lot of the linux commands. So yeah, adapt these lines, put it in a .sh or .ps1 and you’re done. But please test first… as I just wrote this untested.

docker stop -t 300 storagenode
cp /path/to/info.db /path/to/infodbcopy
docker start storagenode
python earnings.py /path/to/infodbcopy
rm /path/to/infodbcopy/info.db
1 Like

Thanks. I got this to work. Very helpful.

Like others I suspect, my actual and projected payouts are much lower than the Storj V3 earnings calculator suggested - even though I have a fast Internet connection. But that’s another discussion for elsewhere.

Thank’s for the good work and bring to us a tool that should be included in the dashboard.

There is a reason for start the node after the earnings script? I usualy start the node after the database copy for keep the downtime as low as possibile.

Starting after copy is fine too. The time difference is minimal though. But I changed it in my previous post.

I have a nice little update today. I noticed that the info.db actually stores storage data from previous months now. Last month it looked like it was there for one month only, but that likely was just because this way of storing the data was started that month. Long story short, starting with September 2019, historic data is now available, meaning that your historic totals should now reflect actual payouts!

Today’s update incorporates changes to actually display that storage information and adds a warning about the missing information for months prior to September 2019. There are some other tweaks as well. Enjoy!

v6.1.0 - Historic storage data

  • Storage information for historic months is now also available starting with September 2019
  • Small change in terminology for used storage to align with planned changes on the SNOboard (GBm instead of GB/Month, which was actually mathematically the wrong unit anyway)
  • USD amount is now shown on the Disk Average Month line
2 Likes

It works like a charm!
Thank you so much for this very usefull tool! It would be great if Storj teams decided to inculde it natively :slight_smile:

Already suggested that and more on the Node Dashboard UI/UX Feedback topic :smiley:

Our Storj friends love to throw me curve balls with updates to the database structure for storagenodes. But they’re not getting me that easily! :laughing:

v7.0.0 - Compatibility with split database

  • Made the script compatible with the split up sqlite3 databases
  • Changed readme to reflect the 3 databases required for the script to work

@Alexey you may want to update the reference to info.db at the bottom of this page as well.


It now requires bandwidth.db, storage_usage.db and piece_spaced_used.db to be copied.

btw… is that a typo in piece_spaced_used.db? That’s actually what the file is called.

1 Like

Love this latest version, it rocks!

Maybe a stupid question: Why do we have some “NOT PAID” lines?

Because ingress traffic isn’t paid and storage is paid only once. I have multiple metrics for storage in there that basically descrive the same thing in different units. The currently stored amount is just what’s stored at this moment. And then there is the average over the entire months and GBh. Since payment is based on the average over the entire months, that line now lists the actual amount.

I have these 2 lines since version 7.0.0 at the top of the output when I run the script.

<sqlite3.Cursor object at 0x7fe9cea99570>
<sqlite3.Cursor object at 0x7fe9cea99570>

Are these error messages or what else do they mean?

1 Like

No, they’re me being an idiot and leaving in some debug code in the version I put on github. Thanks for pointing it out. Fixed it with a minor release.

v7.0.1 - Cleanup output

  • Remove debug print lines
3 Likes

Do the estimated earnings take into account the surge payout (x4 for July, August, September, October)?

Thanks!

No, This is before surge. The surge payouts are different depending on how old your node is. I get 5x because my node existed prior to surge going into effect. I pondered including it but eventually decided against it since this is only temporary.

1 Like