This doesn’t make sense as you get paid $1.50 per TB just for the static storage alone. And usually about the same again for egress. One or both of these numbers are incorrect.
@BrightSilence I think what they meant by…
…is that their node has a total of 25TB dedicated to Storj, but not 25TB of stored data. I may be wrong but it would explain this discrepancy ^^
2 Likes
For myself I will probably give Storj 2 years to make something. Date based on the age of my oldest still running node. That means I have another 13 months to run to just sit and watch what happens. I’m already well in the black on Golem and I’m going to focus future growth in that direction for the moment.
I’m not sure the 10% bonus on zksync means anything right now so long as the current token price stays smashed at current levels.
2 Likes
How is that possible? Golem network stats show about only 5% of providers in use
I can’t say too much here being another project but I’ll message you.
Man i had 1.3 TB in Dec and I egressed 200GB. The variations are real.
Much of the egress happens on recently uploaded data, so full nodes tend to lose out on some egress over time. In my experience it is worth adding HDD space when your node fills up for this reason.
Would it make more sense (from a SNO perspective, this would be bad for the network) to sort of rotate two nodes, once one fills, you empty it while the other is filling? Or is the filling process so slow it wouldnt help? Just curious what the incentive is for old full nodes to continue.
Pretty much this. I don’t have the exact numbers, but I doubt giving up on half your stored data would be worth it. Ideally you use the first node to save up money for the expansion. That’s what I did and I’ve bought 2 expansions already and now most of it is just pure profit. Never spent any money on Storj that I didn’t make with Storj. I mean, even if the income drops for a bit when it’s full, you can still save up for a new HDD. They’re not that expensive anymore. So as long as you have another place to plug it in. Get one at a good price and keep earning.
I mean, it’s still income even if it drops a little. But I do see the drop as a bit of a problem. In the end it will no doubt lead to people trying to do things like you suggest. However, if people at least take the effort to run a graceful exit, there will be basically no harm to the network if they do. If they just kill the node, it would trigger quite costly repair on the network though. But if you plan to stay with other nodes, it would make sense to do the graceful exit anyway.
If I were selfish I should even be encouraging this, because every node operator that exits, gracefully or not, will send more data my way. 
But instead, I’d rather encourage you to follow my path and be the one who receives the data. It’s nice on this side of the fence. 
5 Likes
Oh yeah, Im planning on letting my node just fill and be passive income on a server I owned before, and will after. Hopefully itll pay for the upgrade to a rack chassis. Thats all Im really banking on. Or maybe just new drives. Those 14TB easystores are nice at $200. It just seems interesting that the payment model almost has built in decreasing income for full nodes. No age incentive or retention bonus’. Although they need to work on getting more business first prolly.
This is highly depends on customers behavior, the payment model cannot predict that.
For example, if your node would collect pieces of popular shared files, I would say your income will be great.
From the Community stat the egress almost linearly depends on used space.
What are you referring to specifically here?
Posts on the forum and your Earnings calculator (Update 2022-01-13: v11.0.0 - Detailed earnings info and health status of your node, including vetting progress)
Please correct me, If I’m wrong.
1 Like
Well you’re not wrong in the sense that that’s how it is currently calculated. But I had a suspicion that you were basing it in part on that and that’s why I asked. I have been considering changing how deletes and egress are predicted in the estimator by in part basing it on recently uploaded data, because the trends I have seen suggest that deletes especially, but also egress frequently happen on data uploaded in the same month.
I’ve been kind of putting off implementing those changes though, in part because they are fairly impactful and I don’t have much time to spend on it, but also because as you mentioned this is quite customer behavior dependent and may not always be like this. It is also quite difficult to account for this without having exact data from many nodes. At the moment I’m comparing egress between my nodes that have been full for a long time and my node that has free space to determine the difference. But that’s not a perfect source as those older nodes filled up a long time ago and have more test data than customer data as a result. And at some point I will also have to accept that an estimator can never be perfect.
However, the current calculation should not be used as an indicator that the effect of recently uploaded data being downloaded more frequently isn’t happening. The estimator atm underestimates egress and deletes a little on new nodes as a result of not accounting for this.
2 Likes