# Updates on Test Data

**URL:** <https://forum.storj.io/t/updates-on-test-data/26034>\
**Category:** Announcements\
**Created:** [April 30, 2024, 3:36pm UTC](https://forum.storj.io/t/updates-on-test-data/26034 "2024-04-30T15:36:45Z")\
**Posts on this page:** 20\
**Page:** 54

<div class="post-metadata">

**Author:** ![Mitsos](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mitsos/32/1125_2.png) [@Mitsos](https://forum.storj.io/u/Mitsos)\
**Post date:** [June 13, 2024, 2:26pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1190 "2024-06-13T14:26:22Z")

</div>

I don’t see that on my end. If I leave the nodes raw (ie on the internet line I have them on), I’m nowhere near at saturating my connection. If I route them through an EU-central-datacenter, I instantly saturate it and keep it saturated.

That, to me means that nodes closer to the satellite are selected more often. There is no logical scenario in my head that matches the traffic pattern. I can’t saturate my link, but routing half-way across the globe (+added vpn overhead) gets it saturated?

---

<div class="post-metadata">

**Author:** ![littleskunk](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/littleskunk/32/63_2.png) [@littleskunk](https://forum.storj.io/u/littleskunk)\
**Post date:** [June 13, 2024, 2:29pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1191 "2024-06-13T14:29:54Z")

</div>

> [@Mitsos](#):
>
> Correct me if I’m wrong, but weren’t you guys saying that with the reserved capacity there would be enough online capacity and we don’t need to add anything else?

Capacity yes but we are concerned about throughput. Bringing online a 1 PB of storage on a 100MBit/s connection isn’t going to help. I think we filled like 3000 nodes in the past week. So if these nodes would add some extra hardware drives (if possible with their setup) that would get us back to the throughput we had a week ago.

> [@Mitsos](#):
>
> I was the one that asked for a timeframe on how soon you want us to add disks. The reply was “you don’t need to add anything now”.

That is an old statement. We now see that the number of nodes with free space needs to stay high enough. So any additional node on a different internet connection or additional space on full nodes helps.

Not useful is to add an additional 1 PB to the 100MBit/s node I mentioned above.

I can’t even predict for my own nodes how much used space I will have at the end. As explained a few posts earlier we are trying to reserve enough capacity in the network to answer that question. In the meantime we are preparing some alternative solutions to that problem. The surge capacity would be short term.

---

<div class="post-metadata">

**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\
**Post date:** [June 13, 2024, 2:38pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1192 "2024-06-13T14:38:28Z")

</div>

> [@Mitsos](#):
>
> I don’t see that on my end. If I leave the nodes raw (ie on the internet line I have them on), I’m nowhere near at saturating my connection.

Ah, I get it. I can see they can cap my Internet connection… but I haven’t filled any HDDs. So I just watch and wait…

---

<div class="post-metadata">

**Author:** ![Pentium100](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pentium100/32/6082_2.png) [@Pentium100](https://forum.storj.io/u/Pentium100)\
**Post date:** [June 13, 2024, 2:45pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1193 "2024-06-13T14:45:15Z")

</div>

For now I have enough free space both on the node and in the pool. I increase the size of the virtual disk and the node when it is close to running out of space. Expanding the pool may pose a problem, but there is enough space for now.

---

<div class="post-metadata">

**Author:** ![BrightSilence](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/brightsilence/32/6048_2.png) [@BrightSilence](https://forum.storj.io/u/BrightSilence)\
**Post date:** [June 13, 2024, 3:14pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1194 "2024-06-13T15:14:57Z")

</div>

I’m a little wary to expand right now, even though I don’t have enough nodes with free space to use all my IP’s. The main reason is that at the moment uncollected garbage and trash account for almost a third of my used capacity. Something still isn’t working right there. I will probably expand when all nodes are close to full and wait with expanding more until that issue is resolved. I’m also a little worried about what will happen with performance if expiration of the TTL data kicks in combined with large GC runs still needed. This is still an untested load scenario.

A side note: With the new node selection, it may not be all that useful to keep working with multiple IP’s as added load on the system reduces the chance node selection would pick my nodes. It still helps, but not as much. That’s a good thing in general. Though I wanted to keep those IP’s for collecting data for the earnings estimator for different sized and different ages of nodes. However, it’s near impossible now to make a good estimation as node performance can have a big impact. It’d be awesome if we could get average stats on ingress per node with free space.

---

<div class="post-metadata">

**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\
**Post date:** [June 13, 2024, 3:32pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1195 "2024-06-13T15:32:32Z")

</div>

Off-topic: but do I see some 1.105.4 sneaking out? Lets see if my setup can run filewalker _and_ ISP-capping ingress at the same time 😉

---

<div class="post-metadata">

**Author:** ![Mitsos](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mitsos/32/1125_2.png) [@Mitsos](https://forum.storj.io/u/Mitsos)\
**Post date:** [June 13, 2024, 3:48pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1196 "2024-06-13T15:48:31Z")

</div>

So it’s been a little over a month in testing, can we get any update if a client signed/is getting ready to sign, any kind of numbers (ie we are 30% there wrt requirements), or even what the reduction in throughput was after filling the 3000 nodes?

I’m not looking at a mountain of data, just a spec of dust will do.

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [June 15, 2024, 8:26am UTC](https://forum.storj.io/t/updates-on-test-data/26034/1197 "2024-06-15T08:26:46Z")

</div>

3 posts were merged into an existing topic: [Can’t split load on multiple nodes. Why?](https://forum.storj.io/t/cant-split-load-on-multiple-nodes-why/26483/13)

---

<div class="post-metadata">

**Author:** ![Ruskiem](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/ruskiem/32/64_2.png) [@Ruskiem](https://forum.storj.io/u/Ruskiem)\
**Post date:** [June 13, 2024, 5:46pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1198 "2024-06-13T17:46:57Z")

</div>

> [@littleskunk](#):
>
> We are working on a few plans to increase throughput. One of the plans is that we rent out a few servers ourself to fill the inital gap. So if your nodes can’t take the load we might just add 1000 nodes ourself and wait for the network to keep growing over time. We would reduce this surge capacity over time and don’t intend to run it for long. Just some surge capacity for times of rapid grow.

First “Storj’s select”  
now “Storj’s buffer” 😄  
Wouldn’t it be simpler to just $1.5/TB → $2/TB?

just sayin’!  
You know, economics laws and stuff 🙄 😄

---

<div class="post-metadata">

**Author:** ![littleskunk](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/littleskunk/32/63_2.png) [@littleskunk](https://forum.storj.io/u/littleskunk)\
**Post date:** [June 13, 2024, 6:12pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1199 "2024-06-13T18:12:00Z")

</div>

Another good joke. Like the one asking for free hardware. Nice try 🙂

---

<div class="post-metadata">

**Author:** ![MarviBiene](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/marvibiene/32/1124_2.png) [@MarviBiene](https://forum.storj.io/u/MarviBiene)\
**Post date:** [June 13, 2024, 6:24pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1200 "2024-06-13T18:24:21Z")

</div>

I don’t quite understand. The satellite knows the right amount of data stored per node. So why is it reporting a wrong stat to the node? Is there a difference?

---

<div class="post-metadata">

**Author:** ![Mitsos](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mitsos/32/1125_2.png) [@Mitsos](https://forum.storj.io/u/Mitsos)\
**Post date:** [June 13, 2024, 6:26pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1201 "2024-06-13T18:26:45Z")

</div>

> [@littleskunk](#):
>
> Another good joke. Like the one asking for free hardware. Nice try 🙂

I like the one where we add another ISP line in anticipation of maybe using it. Personal preference though, YMMV.

---

<div class="post-metadata">

**Author:** ![littleskunk](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/littleskunk/32/63_2.png) [@littleskunk](https://forum.storj.io/u/littleskunk)\
**Post date:** [June 13, 2024, 6:37pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1202 "2024-06-13T18:37:22Z")

</div>

You might have misread that somewhere. I explained why we are going to plan on adding surge capacity so that nobody has to take unessesary risks. That also covers adding another ISP line. With the surge capacity we are going to buy time so that the network can adopt to what ever the new situation will be.

---

<div class="post-metadata">

**Author:** ![Mitsos](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mitsos/32/1125_2.png) [@Mitsos](https://forum.storj.io/u/Mitsos)\
**Post date:** [June 13, 2024, 6:38pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1203 "2024-06-13T18:38:33Z")

</div>

> [@littleskunk](#):
>
> so that the network can adopt to what ever the new situation will be.

Those are very strong words, I suggest “may be” is more appropriate.

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [June 13, 2024, 6:38pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1204 "2024-06-13T18:38:56Z")

</div>

how it will work? like temporary buffer? and then upload it to nodes? it will add speed to client uploads.

---

<div class="post-metadata">

**Author:** ![pangolin](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/pangolin/32/15685_2.png) [@pangolin](https://forum.storj.io/u/pangolin)\
**Post date:** [June 13, 2024, 7:01pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1205 "2024-06-13T19:01:23Z")

</div>

You pay peanuts you get potatoes. 🙂

---

<div class="post-metadata">

**Author:** ![littleskunk](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/littleskunk/32/63_2.png) [@littleskunk](https://forum.storj.io/u/littleskunk)\
**Post date:** [June 13, 2024, 7:06pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1206 "2024-06-13T19:06:39Z")

</div>

> [@Mitsos](#):
>
> Those are very strong words, I suggest “may be” is more appropriate.

So you expect that we need to run the surge capacity more permanent? That wouldn’t be an issue. We can run the surge nodes for as long as needed. The costs are low enough for that.

> [@Vadim](#):
>
> how it will work? like temporary buffer? and then upload it to nodes? it will add speed to client uploads.

The node selection will look like this. Lets say 95% of the pieces will get uploaded to the public network and 5% of the pieces to the surge nodes. Or what every distribution we need. The numbers don’t really matter here. All that matters is that we will mix them in with our public network in order to boost throughput.

There will be no rebalancing. The pieces that the surge nodes will store will stay there for 30 days. Instead we just reduce the number of new pieces they are getting. A complete shutdown is possible by setting the free space to 0 and just wait 30 days until they are empty.

> [@pangolin](#):
>
> You pay peanuts you get potatoes. 🙂

Give us more potatoes. Thats fine. The benchmark tests are telling us that the potatoes still have decent throughput and will help. This is not a question of hardware. Even an Pi5 has a great time these days. There is no need for datacenter grade hardware. Run what ever you feel works best.

Common can we maybe stop this discussion? I undestand that you have to try to ask for more money. I would do this as well. At the same time I look at my node and the payout is already way higher than I thought possible this year. I can operate my node with that payout just fine. I understand some nodes might have too high costs for bandwidth. Thats ok. We can’t make this a net profit for all nodes. We only have to make it a profit for most nodes like for example my own storage node. Potato nodes are welcome.

---

<div class="post-metadata">

**Author:** ![Mitsos](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mitsos/32/1125_2.png) [@Mitsos](https://forum.storj.io/u/Mitsos)\
**Post date:** [June 13, 2024, 7:21pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1207 "2024-06-13T19:21:55Z")

</div>

> [@littleskunk](#):
>
> So you expect that we need to run the surge capacity more permanent? That wouldn’t be an issue. We can run the surge nodes for as long as needed. The costs are low enough for that.

I know the costs, I wasn’t suggesting you keep running it forever. I was suggesting that if one of the “big clients” has already signed up and “_will be_” is coming into effect, it’s better if the SNOs hear about it. If the client hasn’t signed up yet, that’s where “_may be_” is coming into effect.

Storj labs is reacting on what the numbers are telling it (ie projected sales, network growth, nodes being added/removed). Us SNOs are reacting on what crumbs of information we end up being fed. I think we have a right to be a bit more skeptical about any "will be"s.

---

<div class="post-metadata">

**Author:** ![JWvdV](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/jwvdv/32/7814_2.png) [@JWvdV](https://forum.storj.io/u/JWvdV)\
**Post date:** [June 13, 2024, 7:22pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1208 "2024-06-13T19:22:44Z")

</div>

> [@Alexey](#):
>
> FATAL errors in your logs

Sorry, I have to disappoint you…  
I have explored the logs of many of these nodes that state only to be up for some hours. But for unknown reason, if I look back at the time which they claim to be up for, there is invariable a moment of version-check. But sometimes apparently the version check can’t be fullfilled / server isn’t reachable, and the uptime is being reset in one or another way. I even don’t see a real restart of the storagenode.

---

<div class="post-metadata">

**Author:** ![JWvdV](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/jwvdv/32/7814_2.png) [@JWvdV](https://forum.storj.io/u/JWvdV)\
**Post date:** [June 13, 2024, 7:24pm UTC](https://forum.storj.io/t/updates-on-test-data/26034/1209 "2024-06-13T19:24:10Z")

</div>

> [@littleskunk](#):
>
> Similar performance should be possible with ext4 + inode cache

Can you elaborate on this?

[Previous page](https://forum.storj.io/t/updates-on-test-data/26034.md?page=53)

[Next page](https://forum.storj.io/t/updates-on-test-data/26034.md?page=55)
