Askrene: prune and cap #8332
Open
Askrene: prune and cap #8332
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add log information about the runtime of getroutes. Changelog-None: askrene: add runtime of getroutes to the logs Signed-off-by: Lagrang3 <[email protected]>
Move the feature tuning algorithm to mcf.c, ie. the loops for searching a good mu and delay_feefactor to satisfy the problem constraints. We are looking to set the stage for an execution logic that allows for multiple choices of routing algorithms, mainly for experimenting without breaking the default working code. Changelog-None Signed-off-by: Lagrang3 <[email protected]>
Prefer the following programming pattern:
do_getroutes(){
do_something1();
do_something2();
do_something3();
}
rather than
get_routes(){
do_something1();
do_something2();
}
do_getroutes(){
get_routes();
do_something3();
}
Changelog-None
Signed-off-by: Lagrang3 <[email protected]>
Changelog-None Signed-off-by: Lagrang3 <[email protected]>
Refactor MCF solver: remove structs linear_network and residual_network. Prefer passing raw data to the helper functions. Changelog-None Signed-off-by: Lagrang3 <[email protected]>
The single path solver uses the same probability cost and fee cost estimation of minflow. Single path routes computed this way are suboptimal with respect to the MCF solution but still are optimal among any other single path. Computationally is way faster than MCF, therefore for some trivial payments it should be prefered. Changelog-None. Signed-off-by: Lagrang3 <[email protected]>
Changelog-Added: askrene: an optimal single-path solver has been added, it can be called using the developer option --dev_algorithm=single-path or by adding the layer "auto.no_mpp_support" Signed-off-by: Lagrang3 <[email protected]>
Changelog-None. Signed-off-by: Lagrang3 <[email protected]>
Changelog-None Signed-off-by: Lagrang3 <[email protected]>
Changelog-None Signed-off-by: Lagrang3 <[email protected]>
Constraint the number of flow units to 1M and prune arcs that are provably not used in the MCF computation. Changelog-None. Signed-off-by: Lagrang3 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR depends on #8299 and supersedes #8314.
With this PR I want to make a small improvement to the MCF solver in askrene.
First: I would like to constrain the number of flow units to 1000 by setting the accuracy of the solver
to the total payment amount divided by 1000. Some MCF algorithms like "successive shortest path" (SSP)
have theoretical complexity bounds that depend on that number.
Note: the 1000 number is arbitrary, the smaller it is we may reduce the solver's runtime but we lose
a accuracy.
Second: I would like to prune the set of arcs in the network. I can achieve this by setting a limit to the sum
of the arc capacities that correspond to the same channel to U, the maximum number of flow units
in the payment. Notice that due to the piece-wise linearization of the channel
cost function, one channel becomes several arcs in the MCF network, therefore we can discard the higher cost
arcs of a channel linearization if the lower cost arcs already sum up to U in flow capacity.