Also my other (fully vetted) nodes showing a significant increase in audit traffic. So I guess they silently adjusted something. 
no, i had the identic situation, after 1 month nothing, after 1 month exactly the first audit and in 1 week verified on eu1 and us1, after another month verified on ap1.
I suppose this it’s nomal now with the new percentage of bandwith for new nodes.
Just a note from my end on how vetting currently works. There is a set percentage of total traffic that goes to nodes in vetting state. Meaning x% of traffic goes to unvetted nodes, no matter how many unvetted nodes there are. This system tends towards unbalance.
If vetting is slightly too fast, nodes get vetted quickly and the number of unvetted nodes goes down, causing more data to be sent to unvetted nodes and speeding up the process even more.
If vetting is slightly too slow, it takes longer to vet nodes and the number of unvetted nodes tends to pile up, meaning they receive less data slowing down vetting even further.
No fixed setting is going to fix this. The system needs to change.
There was an issue on GitHub for this and it seemed Storj Labs recognized a bigger change was needed. I posted a suggestion that would have prevented this, but they went with a stop gap solution of just lowering the percentage, which flipped the balance to the too slow side.
Link: Need to retune % of data going to unvetted nodes · Issue #6011 · storj/storj · GitHub
Suggestion: Create a satellite setting to set the % of normal node ingress an unvetted node should get. Calculate the number of pieces to go to unvetted nodes by: (nUnvettedNodes / nTotalNodes) * unvettedTraffic% * nPiecesToSelect
This won’t usually be a whole number. In fact, in the future this will likely be below 1. To resolve that, round that number down and generate a random number between 0 and 1. If that number is below the remainder, add 1 to the rounded down number of unvetted nodes to select.
Using this method an unvetted node would always get x% of the amount of traffic a vetted node would get. And it would remove the impact of the amount of unvetted nodes on the speed of vetting. Though I do realize now that there still needs to be a maximum to ensure not too many pieces per segment go to unvetted nodes. So maybe use the dynamic calculation as long as the result is below 5 (that should probably be a satellite setting too)?
1 Like
Perhaps the network’s used/free space ratio should also play a role in the calculation. If the network is at 20% utilization, new nodes aren’t really needed. If the utilization is at 80% then new nodes are needed fast.
I am a fairly new SNO so I’m trying to better understand how things work. I read that it takes a while to have nodes fully audited and that normally, audits happen with satellites with which you have the most data. I’m located in North America, so satellite US1 was the satellite registering the greatest amount of data when I started (approx 80%). However, audits started with EU1 first even thought only about 20% of the data stored was associated with this satellite. Now, EU1 has conducted 285 audits, but not a single audit has been done by US1 even though it still has to this day the majority of the data associated with it (about 60% of the data stored)
To be clear, I question the fact that not a single audit has been conducted by US1 which is assigning me most of the data stored by my node while EU1, assigning me less data, has had time to fully audit my node more than once.
Runs on Docker / Ubuntu 22.04. My node has been online for 20 days.
Yes, the same pattern I saw too, even though I am in EU, and more audits and data from EU makes sense.
Maybe the US1 is bussier than other servers and does individual audits less often.
But, no worries, in 40 days both will be vetted, EU1 and US1.
For me, EU1 took off after 20 days, and was done after 30 days. US1 took off a little later and was finished in 40 days. AP1 and Saltlake they don’t see a single audit still, and my node is 3 months old.
They should take a look at vetting process to impruve it somehow. Maybe you can do a Github bug report.
3 Likes