Saltlake vetting started?

[pangolin]

@Mitsos

Unvetted nodes get 1% of the new traffic.

Is this really the only parameter for vetting? No time delay or data treshold before audits starting?

[Mitsos]

Yes, that’s what gets traffic into the unvetted node. After that it’s a matter of how much data it has. More data = more likely to get an audit.

@ACarneiro no, benchmarks are unpaid.

@littleskunk

We will do some spot checks regarding the bandwidth our storage nodes have. We will run the new remote benchmark tool against some random selected nodes for a short duration. We are going to use big piece sizes to compensate for the fact that the performance improvements are not rolled out yet. We hope we will still get an accurate reading. The data will be unpaid because we upload the pieces to the storage nodes without commiting the result to the satellite. Garbage collection is going to clean it up later. We will keep the upload burst short to keep the amount of unpaid data as low as possible.

[littleskunk]

You might want to read that text again. Especially the last sentence. I don’t understand why people still believe the current test would be unpaid.

[Mitsos]

So that means that only that one particular test was unpaid?

[littleskunk]

Yes. And it was just 10 segments with 64 MB each. It was a tiny amount of unpaid data.

[Mitsos]

Then I stand corrected.

[Roxor]

I read it the same way you did. I expected the slower/continuous SLC data to be related to the TTL/capacity-reservation plans (so paid)… but the recent high-bandwidth testing to be the performance-data-not-registered-with-the-satellite (so unpaid).

[Alexey]

nope only this one was unpaid:

@littleskunk

And it was just 10 segments with 64 MB each. It was a tiny amount of unpaid data.

[JWvdV]

@Roberto

in the sense that if a new node is started on an IP that already has other nodes checked, it should already be reliable, or at least have a faster vetting process.

@Vadim

it check not only operator but hardware also, mostly people use old hdds, and it you share lot of data to hdd and it die, it is bad for network, so firstly you get little data, to qualify that hardware setup is stable.

I actually don’t care the vetting process that much. As I still don’t see much of a difference between vetted and unvetted nodes. But @Vadim 's argumentation seems to be reasonable, but isn’t. Situations where nodes choke, are especially stress situations: so much data influx in the beginning, might just prevent later problems. The failure of disks is still noteworthy hard to pretell.

So I can follow @Roberto 's reasoning, in the way that apparently those nodes are being held by people who are able to setup nodes. But I would not only check for the number of nodes behind the same IP, but also for the failed nodes behind the same IP last six months and/or from the same operator. And then it becomes quite complex, and is the question whether it’s really worth the hassle.

[snorkel]

Maybe change the vetting process?
https://forum.storj.io/t/strategy-for-testing-new-nodes/26101