Benchmarking virtualfund (TTFP over multiple hops) #1809
Closed
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.
I wrote a benchmark reusing many utils from our integration tests. Quite possible that I made a mistake, it needs a careful double check.
The main test function sets up a network of alice, bob and up to 12 intermediaries. Alice has a ledger connection to the first. Bob has a ledger connection to all of the others.
Then sub benchmarks are run where we make a longer and longer path from alice to bob and create a virtual channel.
The message service was configured with a 100ms delay for realism (we want the network latency to dominate other latencies in the protocol). This is not as realistic as it could be -- consider that if the nodes are physically arranged in a line (or circle, or any 3d arrangement), the latency between nodes will not be a constant.
Results were piped through chat gpt and https://www.tutorialspoint.com/execute_matplotlib_online.php
(very rapid way to get a graph)
Vertical units are seconds, so (10*network-latency).
In theory the TTFP should run in 5*network latency. This is shown as a horizontal line:
Attempt 1
I have also plotted the theoretical behaviour in an HTLC based payment network (green line). The unifying idea is "time to finality on a payment" (in Nitro, to make the funds usable again we have to virtualdefund in addition, whereas in Lightning they are usable straight away. But we get finality before then. ).
Conjecture: The test message service is delaying messages in a blocking manner, whereas we want to delay concurrently across nodes.
Attempt 2
Conjecture: The actual latency is not well modelled by our use of "max delay"
Attempt 3
Fixing the delay rigidly gives results which agree pretty well with the theory:
There is an increase as the number of hops goes up... but much more slowly than "a roundtrip per hop" which is what we get with HTLCs. Consider that this is all running on my laptop, so one expects some slow down as the system becomes more complex.