If the new node selection considers performance… does that also help nodes that have neighbors?
Like I know my IP has other SNOs in my /24, so historically I could expect to share about equal ingress with them. Fine. But now if my node is faster… could the new selection criteria perhaps steer extra data my way?
I’m more likely to try to tune things for speed… if I knew I wasn’t completely stuck behind forced-sharing with slower neighbors 
I’m surprised that you haven’t done it already tbh 
From how I understand node select works, your node will be picked the same amount of times are your neighbors.
Better performance will impact how often you win when “matched” against other nodes during bestofn, but it does not at any point have any effect on how often the nodes are picked.
E.g. A node with a 0% success rate, will be picked exactly the same number of times as any other node (ignoring neighbors), but will be “filtered” during the bestofn selection.
Expanding on what @pasatmalo said. You likely do get a bit of a benefit compared to before. With your node getting a lower load it will likely lose less races and will benefit in most bestofn comparisons. But you still get fewer chances to be part of such bestofn comparisons.
Time for another update.
We are going to run a few performance tests on US1 today. On SLC the RS numbers have been set on a global level. On US1 they would need to be set on the bucket / project level. We want to try that out today and also test out if the US1 satellite can handle the load as good as SLC did. If we are lucky they are going to keep the test running for a few hours.
This is still testdata and no customer data. Just uploaded over US1 this time.
a lot of node operators have been working speed, but mainly just to survive used space and garbage collection filewalkers.
For me, actually “responding with the requested data” has been the easy part so far.
Would this test data have TTL ?
I don’t know. I am on a call setting up that performance test. I will have to double check.
Edit: Looks like if we don’t screw it up it should be 30 days TTL again.
will it be in paralel with SLC test data or you turn off it for that time?
SLC will be paused. I would expect that we stop if for 24 hours and decide tomorrow when and with which settings we want to restart it.
Statistics Show that US1 even all the time on same load as SLC, it looks like all this go to SOC2 mostly, as we dont see same big ingres from US1. Interesting what will happen if Storj adds more same as SLC load.
It is a bit early for that conclusion. We need a few more tests.
omg. I forgot saltlake satellite with all nodes a couple of days ago to escape from ttl madness… There is no peace for a quite modest SNO
Sounds like a you problem. Feel free to graceful exit US1 as well.
Raise your hands if you can’t get expired ttl data deleted regularly and correctly 
Btw, I will never exit a customer satellite. I’m ready for new tests in US1 
I have tested the corresponding fix for that. It isn’t ready for merge yet but it does look promising.
I read about that a day after my exit 
I am fully confident that everything will be resolved before the real data arrives.
I had full 20tb nodes with about 50% of paid data so I decided to exit tests and dont miss real us1 and eu data (more stable and less bandwidth stress)
From 18tb to 6
For me test-ingress looks close to idle for the last 4 hours (since littleskunks update). That’s fine: I’m just also confirming it doesn’t look I’m getting about the same traffic just from a different satellite.
We found a bug and have to deploy a hot fix real quick. And by quick I mean full run of the bild pipeline with all the automated tests in it. In about 20 minutes we can try again.
I think you understood it wrong.
this was about
Usual ingress on US1 and SL is almost same, but we see big ingress in nodes only from SL sat. this mean that most ingress on US1 go to SOC2 nodes only, but US1 looks like havely loaded with it.
this was not about today test at all.