Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

N showing 0 #24

Closed
rebroad opened this issue Jan 1, 2017 · 6 comments
Closed

N showing 0 #24

rebroad opened this issue Jan 1, 2017 · 6 comments

Comments

@rebroad
Copy link

rebroad commented Jan 1, 2017

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).

@ayeowch
Copy link
Owner

ayeowch commented Jan 2, 2017

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 ayeowch closed this as completed Jan 2, 2017
@rebroad
Copy link
Author

rebroad commented Jan 2, 2017

@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?

@ayeowch
Copy link
Owner

ayeowch commented Jan 2, 2017

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.

@rebroad
Copy link
Author

rebroad commented Jan 2, 2017

@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?

@ayeowch
Copy link
Owner

ayeowch commented Jan 2, 2017

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 :)

@rebroad
Copy link
Author

rebroad commented Jan 2, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants