N showing 0
rebroad opened this issue · 6 comments
https://bitnodes.21.co/nodes/leaderboard/?q=satushi
My node for the last few months has been getting an N value of around 0.43 (>0.51) yesterday, resulting in my node getting to position 1 in the leadboard. Today, the N value is zero. Has something changed at leaderboards or is my node suddenly (without reason I am fathom) stopped sending addresses? (Seems very unlikely that it can still be up yet not sending addresses).
Your nodes should have NI set now. It was set to zero by error when a new fix for NI calculation was being deployed.
@ayeowch What changed? My node's N was 0.51, and now it's 0.053. Why is it capped at the 99th percentile now?
I have updated the doc in https://bitnodes.21.co/nodes/leaderboard/#peer-index:
NI = Nodes index
NI = (p ∩ N) / N
p = peers returned in addr responses
N = reachable nodes
NI >= 6σ is capped at 99th percentile
Threshold of 6 standard deviation of the NI values is used to handle very extreme NI values that would greatly inflate the overall index even with very low values for other indexes. Majority of the nodes are at most 2 standard deviation. Note that NI values at 3 to < 6 standard deviation are tolerated and not capped.
@ayeowch Ok, so I notice you have changed the algorithm and introduced winsorizing, which is supposed to be used to avoid a value being influenced by outliers. However, 1) there was no value being influenced by an outlier, and 2) the were no outliers (i.e. nothing caused by experimental error or variability in measurement), therefore it seems highly misleading to introduce this capping. Can you explain why it was done please?
Only the NI needs capping using the described method at the moment. Ideally, there should be fairness across all the indexes used to calculate the overall PIX, i.e. the capping of NI should not affect your ranking if your other indexes are in the lead among the nodes. I am open to alternative method to better calculate NI or even adding new indexes.
Thanks for mentioning "winsorizing", I wasn't aware of it until you mention it :)
@ayeowch I am in favor of fairness, but from my perspective, the capping introduces unfairness - yes, my node fared badly in terms of ASN, but it made up for it in terms of useful addresses, so nevertheless deserved the number 1 position. I think the algorithm was better without the capping, as before it would encourage other node maintainers to improve their address management algorithm (as I did).
With the capping in place as it currently is, it blinds people to potential improvements to address management they may be making.
Also, in terms of node usefulness, I would have thought that providing healthy addresses was a more important factor than how many other nodes share the same ASN and so the previous algorithm was fairer in this sense also.