March payment drastically low?

That is expected even on the best hardware, despite what the official estimator says. Please scroll up a bit to find my alternative and use it to calculate what to expect. You may still decide it’s not worth it, but you’ll have a better indication of where it might go.

Edit: I’ll make it easier. Here’s the link. Save the sheet to your own drive to enter your info.

Good luck with that. I briefly looked into it some time ago. Depending on the amount of space you want to share, you need to spend a few hundred USD as collateral if you want to rent out hard disk space. If your hard disk dies, your collateral is gone. I rather prefer the STORJ model, where you don’t risk money upfront.

As for the profitability of SIA, look here
https://hostrevenue.siacentral.com/

Looks abysmal to me…

4 Likes

yeah my ssd cache is stressed a lot at times 30ms backlog recently just got it down there from 100ms, but i really need to distribute its loads a lot, which was why i tried getting 24gb more ram and to run vm’s better

the graceful exit protocol looks harsh imo, i would hate to go through it at the best of times…
ofc one does get the 2½ month saved escrow back, but data transfers are not paid, and its easy to get DQ from what i understood… so really i would almost say its better to keep the node running if at all possible.

well now i’m up to 10 drives, thus thats an annual failure rate of 10-20%, if you run 10 nodes instead you would still have the same odds, just than when a node fails you will have to get it revetted, and if data is requested from only one drive your system is more stressed / limited, which might increase the likely hood of disk failures, but thats pretty difficult to evaluate without knowing the inner workings of storj, or have long term real use case testing.

clearly we don’t think a like on this matter, doesn’t mean either of us are right or wrong… different approaches to the problem, you do usually have very sensible things today, but in regard to data storage i doubt we will agree much lol but i’m still very much learning what data storage even means… imo it’s not easy to understand…

sadly it seems one cannot store data eternally… or i just havent figure out how yet… shakes fists damn you cruel universe.

@vargrant
yeah also looked into SIA last year or so, but decided against it because it puts stress on the drives if they are sending data to customers or not… didn’t really like that idea…
so i decided to use storj because it seemed the most sensible platform i found.

This is how my latest 7 days has been running Storj from my firewall point of view
1.54 TB in
0.047 TB out


This is reflected in the storj dashboard as well. I’m going to rename my node to blackhole

1 Like

A lot of download is happening, but it’s almost all from the stefanbenten satellite. This is kind of an artifact of the switch to the new testing satellite I think. While upload is happening there, download tests are still being performed on the old test satellite.
image
I’m sure once they’re happy with the amount of data uploaded for the new testing satellite, they will move that download traffic over there and delete the data from the old one. Just hang in there for a bit, I’m sure more download is heading your way soon.

We may think more alike than you think. If you have 10 HDD’s by all means go with RAID6. It’s not likely you’ll be filling all of them up anyway and it makes for a less complex setup.

I just don’t think that’s the correct advise if you have 4 or fewer HDDs. And I’m not a fan of people saying Storj requires high end hardware. Trust me, that’s being said a lot. And then I look at all the raspberry pi’s running nodes and I think… how can you even claim that?

But to be fair, I’m currently using a Synology Hybrid RAID array with 8 HDD’s and 2 disk redundancy and an SSD cache. I didn’t create this array or the cache for Storj and I wouldn’t have if I didn’t have it already. But my choice was to start with the spare space on that array. I did end up expanding that array, because at that point, my choice was run another node on a separate HDD or add the HDD to the array and get the simpler setup and free disk failure protection without any loss of disk space. At that point it’s an easy choice.

So I’m not anti RAID. I just don’t think it should be the default advise.

1 Like

seeing about the same numbers here… a little less than 4-5% egress to ingress ratio.
my guess would be thats what most nodes see… atleast if they are working semi correctly, ofc age might play a factor…

also getting about the same ingress got 2.3tb since the first… but had a few off days where i did some radical testing now that bandwidth was stable, which failed and some of the satellites got a bit offended by or something…

people will always complain… when i suggest a span to somebody with 1 filled drive and wanting to add another… it was a pretty simple solution… granted not super safe… but two drives thats like 2 -4% annual chance of failure the damn thing might run a decade without issues…

so yeah i’m with you on that, i just been around IT long enough that i don’t want to deal with bitrot and such things… so i run zfs raidz and plan to get a DAS just because, and it would be cool if it didn’t cost much to keep it running and i can still use it for other stuff…

so i don’t really expect storj to make me money or anything… its just a fun little pet project.

i’m also told that to make money one should go into it expecting to make nothing lol…

That’s the right attitude. :wink:

I saw elsewhere someone posted they spent 600GBP and got 1000GBP of fun out of it. :slight_smile:
Hard to argue with that.

1 Like

the lol for today was the system message i got a short while ago… apparently i cannot say storj is rapping my disks… xD

pricelss

Not unreasonable… I actually hesitated quoting that line. I now edited your quote in my post. :wink:
But I would agree that’s it’s not preferrable to use such language. It can hit home for some people much more than you intended.

You and I definitely love our long posts. But it’s good to share a lot of information. So, here’s another long post.

In terms of Node profitability, you are right that the actual amount of customer data on the network and the type of use case (low vs. high bandwidth, long-term vs. short-term storage) have a huge amount of impact on what Storage Nodes earn.

In terms of expectation management, the estimator assumes a mature level of network utilization. Any calculator we publish is going to naturally have a point of reference to the amount of usage on the network. The assumptions baked into the current estimator are based on a future state where most Storage Nodes are getting about 50% utilization across the whole network. We chose that as the baseline set of assumptions (as opposed to early network state) because we are looking for Nodes that will join and help grow the network for the long term. That also aligns the interests for Storj, SNOs and customers.

We just launched the production service on March 19. It will take time to acquire new customers, to onboard developers, build out the partner ecosystem, and onboard large amounts of data. Any new storage platform has the same set of challenges, but we have the added challenge that the majority of our infrastructure is operated by people outside the company.

We use tactics like surge pricing and test data to bridge the gap between when we build and launch the service and when the amount of customer data stored and bandwidth utilized creates a balanced network where it’s profitable to be a Storage Node without any subsidy from Storj.

We’re not there yet, but we also don’t expect to be there for some time. The amount of STORJ a SNO can reasonably expect to earn on the network a month into general availability is very different from a point in time where there are thousands of people storing PB or even EB of data, and especially where the platform supports a wider range of use cases with higher bandwidth utilization.

What are we doing to get there? Our strategy is fairly straightforward.

  • We launched the service with a specific set of launch qualification gates, and based on our performance, durability, availability and other metrics, the current network supports a range of initial use cases.
  • The use cases we’re pursuing with developers, partners and customers are based on what the network can successfully handle and the types of use cases those early adopters are willing to try on the network.
  • Our roadmap is geared toward differentiating our service within existing use cases and expanding into adjacent use cases where there is customer demand.
  • In addition to product work, we are actively building our partner network and continuing our marketing and PR efforts to grow our customer base.

What can you do to help? Obviously, by providing reliable storage and bandwidth to the network you make the network possible. We’re in this for the long haul and we need you with us. If you have the opportunity to help drive usage and adoption of the platform - even better. Whether you recommend us to a partner or for a project, blog, tweet or post about the platform, everything helps to grow the network.

1 Like

For me thats not the case, but that might be related to my node being fairly new (feb) - its about 25% ingress vs egress on stefan, and that in total is <1% from my point of view that node is de-commissioned

based on the new test-traffic-pattern its not likely it will have any effect. we talk about 90% of the traffic never being downloaded. sure this might reflect a real use case senario with one customer, and its a bit disappointed but I do understand the math

why would you need a ssd cache? 100ms in access time is horrible and seems to be related to something else.

I think an assumption of 50% use of the network is pretty fair. But it breaks down when you apply it to individual nodes. A new node won’t see anywhere close to 50% storage being used, while a very old node is likely just full at some point. Right now you see that the calculator assumes nodes fill up to 50% in the first or second month for most reasonable sizes and speeds. If that were really the case, you would have a massive capacity problem on the network in the 1 or 2 months that follow. With larges usage and more active customers, the number of nodes will scale as well. So while we can’t be sure what the exact speed of filling up the available space is, we can be certain it would never be 1 or 2 months. This discrepancy is the biggest reason people are disappointed by their earnings in the first few months. Yesterday another person said: “I’m going to stop, because I made almost no money in the first 4 months”. You don’t want to lose SNOs before they have even seen their earnings potential. And a correction to more realistic inflow of storage in the early months would show them that they may not have made much less, but it will get much better over time. An average of 1TB data growth per month per node is in my opinion still a very optimistic estimate even when the network is much larger and has many more customers. While we can’t know the exact numbers, we can narrow it down to something much more reasonable. Furthermore, the 50% usage limits actually limits earnings potential in later months for no good reason. Even in the future state, nodes are unlikely to stop filling up when they’re at 50% storage. Most likely growth in demand will be offset by new nodes joining the network and possibly old nodes expanding. I see no reason to limit earnings potential in the calculator to 50% of storage used. My 11TB node is already storing 7.7TB, so 70% and counting. So while I can see the network as a whole staying at around 50% of storage used, it won’t be like that on individual nodes unless customers also delete the same amounts of data as they upload. Which I don’t see happening for years to come.

As for the % of data downloaded. That will likely fluctuate more based on the use cases on the network. I find it completely reasonable to be a little optimistic there. So by all means, make it higher than the 10% I used. But the important part is not to ignore the relationship between the two altogether. Again, we may not know what that relationship will be in the future, but we definitely do know there will be one and we can make a realistic enough prediction at least for the upcoming years.
Because currently, we can make the calculator say really weird things…
image

@vargrant I don’t know if you looked at the alternative calculator I linked you to, but I would love to hear whether that encouraged you or discouraged you to keep going.

For anyone else who gave it a try, I’d love to hear your response to this as well. Are you more likely to keep your node going if you compare it to the original estimator or my suggested version?

@john I completely understand that you’ve only just started and I understand that you’re doing a lot to keep SNOs happy while you’re onboarding actual customers with test data and surge payouts. It’s very much appreciated and it makes sense that that is required early on. But there is no kinds of test traffic you can generate that don’t need time to fill up new nodes. Nor is there any kind of customer use that would do that in 1 or 2 months. If you show SNOs that early months may cause low profits, but it goes up a lot over time, I’m certain you’ll prevent SNO churn early on and get much more loyal and happy SNOs instead.

3 Likes

I completely agree! This is how it should be.

I also think that people see the high numbers which makes them go spend money to start there node, because they think they will make it back in a few months or less. This seems like a huge issue and I’m seeing it more and more people are spending there hard earned money thinking they will be making bank.

I love how you explain things and fully detail it out. I think new SNO need to know the truth before they go out and buy hardware and just take this process slow and see how it goes.

3 Likes

@direktorn
it’s backlog, according to netdata a monitoring software i’m using.
i put the OS on a partition, the L2ARC and the SLOG on it… so i’m pretty sure its partially due to that, and just high activity on it from storj, and its a semi crappy 750gb sata ssd… might try to move my OS to dedicated drive instead… see what that does

and its only brief spikes, have gotten them down to 30ms by adjusting max concurrent down to 14 in my storj config.yaml
partly why i haven’t tried to move the OS yet… i kinda doubt it would even help.
maybe its just the ssd thats crap… i think its an mx400 from crucial.
which isn’t to hopeless, ofc compared to nvme over pcie or optane… then its like a horse and cart xD
also like you say, i’ve been considered just turning off the L2ARC since i’m not convinced i’m even getting much performance from that anyways… and that would be a very easy thing to do.
maybe thats where i should start.

did some more digging, the MLC technology even on PCIe while working will have latency of 30-50ms, ofc most of the time it has much less and it does soak up a lot of work for the regular hdd’s, the reason i wanted it, is because i plan to run some VM’s and other stuff on the ZFS pool, also i was thinking that even with storj, then some data retrieval will have frequency to it which the L2ARC will help improve.
but it seems i will need to get a proper NVMe ssd over PCIe to keep the latency under load in the single digit ms range.