Storage node reputation and network utilization

Hello,

I have set up two nodes:

  • one on my home, with a 5 TB disk and a VDSL connexion (100 Mbps down / 20 Mbps up), started on 01-18-2020. It has 4.5 GB of egress and 1.18 TB.h.

  • one on a small server on ovh (ovh.com) with a 500 GB and a bandwidth of 100 Mbps started on 01-22-2020. It has 2.5 GB of egress and 123 GB.h.

This nodes have audit and uptime checks of 100 %.
May be I am too impatient but I think that there are not used as attended. I do not see an amelioration over this few days; the egress does not increase even slightly.

So I would like to have more information on how the reputation grows and if my node will be more used in future.
Should this reputation grow faster with a more important bandwidth ?

Thank you

Nodes need to be vetted first, before being considered reliable by the network.

This process usually takes at least a month to complete so things should get better with time.

Also, the more data a node is storing, the more it is potentially queried.

In short: yes, it’s normal to get only small egress on young nodes. It should gradually get better with time, but no one can tell for sure how much better though: that depends on many things…

Welcome

I just want to say your nodes are very new in order to completely become vetted your nodes need to have 100 Successful audits on all the satellites to become vetted to each this doesn’t happen over night you may not get any audits for days in some cases there completely random.

You need to have patience as the starting process takes time, you have to become a trusted Node before getting any kinda real data consistently.

Also keep in mind datacenters are on a shared subnets so if any other SNOs are running in the same datacenter you maybe sharing data.

Thank you for your replies.

So I will be patient !

@deathlessdd Can you tell more about sharing data with node on the same subnet (may be some docs) ?
Because it hurts my comprehension of the network. In my mind, it does not depends on sub layers of the network stack. Like you are saying, I understand that it would be a common pot.

Another questions:

  • Can I reject some datas which are not used and not generate uploads ?
    As customer of the network, can I also choose where to place my data ? Can I choose to spend more to put them in a node with a large bandwidth, a low latency,… ?

Or in other words, who decides where datas will be placed ?

Thank you again, I am still discovering storj, I like the concept but I have some questionings.
I’ve done quite a bit of reading docs, blog posts. May be I have to do more.

Theres a few places on the site that talks about the subnets heres a link to the convo Subnets
Basically its to make the data decentralized we dont want all the data be in the same place or same country. Also pervents people from running 100s of nodes in a central place with all the same data, so if there was ever an outage the data would still be located somewhere else.

You should not reject any data coming into your nodes.

Currently there’s no settings for this but im guessing in the furture there will be a way.

Just remember nothing is set in stone as of right now because its still beta and theres lots and lots of testing putting the network though its paces it can only get better with time.

Thank you, I understand the relevance of avoiding the data to be stored at the same place for the reliability of the replication.

My question is more if I can do that. I understand that is not healthy for the network to do that , but I also see that is not healthy for my node to have just frozen data in it.
And if there is an parameter to filter what I want to host, I think that there will be a lot of nodes monopolizing “valuable” datas.

So I see that the agreement between nodes and the network should be less static.
I would want to decide how I want to participate to the health of the network, and the network should also decide how it can participate to the health of my node.
May be it could be relevant to dynamically set revenues for storage and upload.