2 of my nodes on v1.141.2 gets vetted by all satellites, those on v1.139.6 onlt gets vetted by us1.storj.io
normally they all vett wihtin 3 days of each other
just an observation i made, anyone else seen the same?
does it matter?
node id of the 2 that dont get vetted fully:
1ueCWYzkFRWX4CgZ8gJ4XMhMEcGoyfi6DdP3eEpM35sNHwWGnV
1msiMKjpb9ZuXvHUPMEeXkpHGnvtq4qUKWQCWEDiim5x1comDd
Yes, unvetted nodes having much higher ingress atm. 
what makes me scratch my head is that the higher versions now seems to get vetted with a few days between each satellite giving its stamp of aproval
the lower versions seems to be stuck with only the us satellite doing the vetting… well… i’m just confused
improvements has been started with vetting period. The goal is to have more reasonable period instead of 1-2 days. As US1 is doing audits with higher rate, your nodes were vetted before the change.
It’s not related to any version (IMHO).
i just got confused 
just curious, what does the vetting process include?
100 successful audits from the satellite.
It use to be, but as a quick workaround, we adjusted the values per satellite. Commit isn’t public, issue it’s Nodes are vetted too quickly · Issue #7678 · storj/storj · GitHub
Why only audits? Why not network speed etc?
Because the nodes are already more unattractive when their overall speed is slower. An audit vets the connectivity and data integrity of the nodes - which is far more important than speed. Once a critical mass of nodes have amassed (they have), separate functions can keep track of selecting the most efficient nodes for up/downloads
It also just impossible to measure it. Your node has been contacted by thousand customers across the globe. Each measurement will be unique, it’s interesting, but not useful. Speed between auditors and your node is not interesting.
As @Ottetal said, the node selection is a separate process. First we need to make sure that your node is able keep the data and do not alter it or lose.
Even with most recent changes unvetted nodes having higher ingress than vetted nodes. If this is the case vetting is pointless and could be abolished in my opinion.
would it make sense to include uptime as a metric?
my thought is that if the uptime only goes up it also mean that the node operator only touch thing if they relly need to… ie experimenters that changes stuff and reboot a lot would get a lower score
That’s fair point, but instead of abolishing, I would prefer to fix the original problem: and give only a fair share to unvetted nodes:
it’s handled separately too - as an online score within 30d window. Since your node is new, it doesn’t have enough audit history, so the online score is pretty sensitive and your node may quickly being suspended for being offline too often.
i think you misread… it was mentioning uptime, not online
Uptime is tracked by the online score. It’s a simple math, not untrusted reports from the node 
The uptime on the dashboard shows how much time passed since the last restart and not necessarily being online, so kind of useless unlike the online score which is trackable and accountable measure and this is why it’s included to the node reputation, which consist of:
then what in the case where a node is restarted often?
it can still have a high online % but i would call it unstable as now you cant depend on it as much
but then again i just think without a filter
This is a probabilistic model anyway, it can be selected for audit exactly when it would restart, since it has less audits due to less data, it will heavily affect the online score, it even can be disqualified if it would become 0.
I guess you can’t share publicly the amiunt of audits for the vetting? I am anxiously waiting for the vetting period to be over for my newest node!
Just… stay calm 
- nothing dramatic happens after vetting. The real milestones are after 9-months when you start receiving full monthly payouts - and after 15-months when you get half your withheld coins back 
