Skip to content

plugin-askrene: cap dial iterations to avoid redundant solver runs - #9735

Open
aryarathoree wants to merge 1 commit into
ElementsProject:masterfrom
aryarathoree:fix-askrene-mu-cutoff
Open

aryarathoree wants to merge 1 commit into
ElementsProject:masterfrom
aryarathoree:fix-askrene-mu-cutoff

Conversation

@aryarathoree

Copy link
Copy Markdown

Problem

As reported in #9726 by @ksedgwic, when no route fits maxfee, linear_routes() in plugins/askrene/child/mcf.c executes 28 solver runs before failing.

The 17 runs above (\mu = 0.95) (up to near_one = 1. - 1e-6) can take up to 10× longer on mainnet nodes without improving the found fees. This frequently causes callers with tight fee budgets (e.g. rebalancers) to hit askrene-timeout.

Solution

Cap near_one at 0.99. This limits the solver loop to at most 15 runs, cutting off the slow iterations with diminishing returns above (\mu = 0.95) and avoiding unnecessary timeouts.

Fixes #9726

Checklist

  • The changelog has been updated in the relevant commit(s) according to the guidelines (Changelog-Fixed:).
  • Tests have been added or modified to reflect the changes.
  • Documentation has been reviewed and updated as needed.
  • Related issues have been listed and linked (#9726).
  • Important: All PRs must consider how to reverse any persistent changes for tools/lightning-downgrade (N/A, internal heuristic).

Comment thread plugins/askrene/child/mcf.c Resolved
The retry loop around the solver in linear_routes() repeatedly doubles
the odds mu / (1 - mu) when the route fee exceeds maxfee. Previously,
the cut-off was set to `near_one = 1. - 1e-6`, requiring 27 retries
(28 solver runs) before failing.

As reported in ElementsProject#9726:
"The 17 added runs are at mu above 0.95, where a run is slower and the
fee found changes little or rises... Effect on a mainnet node that
rebalances with a tight fee budget, v26.06.10 against v26.06.9: the median
rebalance request takes 26 s against 5 s, and 12.8% of them end in the
timeout (askrene-timeout 30); none did before."

Introduce `max_mu = 0.99` to cap mu iterations while keeping
`near_one = 1. - 1e-6` for delay/hop dials and the flow_fee_adjustment
fallback. This bounds the maximum number of solver attempts to 15,
avoiding the diminishing-returns iterations above mu=0.95 where fee
priority is already ~99% and MCF solver passes become significantly
more expensive without improving found fees.

Fixes ElementsProject#9726

Changelog-Fixed: askrene: bound dial iterations to avoid redundant solver runs when fee exceeds budget.

This branch has not been deployed

No deployments
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

Successfully merging this pull request may close these issues.

askrene: getroutes makes 28 solver runs when no route fits maxfee (11 before #9627)

2 participants