Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Reduce historical bucket size from 16 bits to 13 bits
Utilizing the results of probes sent once a minute to a random node in the network for a random amount (within a reasonable range), we were able to analyze the accuracy of our resulting success probability estimation with various PDFs across the historical and live-bounds models. For each candidate PDF (as well as other parameters, including the histogram bucket weight), we used the `min_zero_implies_no_successes` fudge factor in `success_probability` as well as a total probability multiple fudge factor to get both the historical success model and the a priori model to be neither too optimistic nor too pessimistic (as measured by the relative log-loss between succeeding and failing hops in our sample data). We then compared the resulting log-loss for the historical success model and selected the candidate PDF with the lowest log-loss, skipping a few candidates with similar resulting log-loss but with more extreme constants (such as a power of 11 with a higher `min_zero_implies_no_successes` penalty). Somewhat surprisingly (to me at least), the (fairly strongly) preferred model was one where the bucket weights in the historical histograms are exponentiated. In the current design, the weights are effectively squared as we multiply the minimum- and maximum- histogram buckets together before adding the weight*probabilities together. In the next commit, we'll square the weights yet again before the addition. However, as we do so we quickly run low on bits in our fixed-point arithmetic. We have 16-bit buckets, which when raised to the 4th can fully fill a 64-bit int. Additionally, when looking at the 0th min-bucket we occasionally add up to 32 weights together before multiplying by the probability, requiring an additional five bits. Here we prepare for this by storing a bit fewer states in each historical histogram bucket - 13 bits instead of 16, with a 4-bit fixed-point scheme instead of a 5-bit one. This reduces the number of payment attempts we can realistically track but in exchange allows us to
- Loading branch information