Summary: | pasta significantly underperforms slirp4netns when connecting to a genuinely remote host | ||
---|---|---|---|
Product: | passt | Reporter: | David Gibson <dgibson> |
Component: | general | Assignee: | nobody |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | sbrivio |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux |
Description
David Gibson
2023-06-08 05:08:32 UTC
See also https://bugs.passt.top/show_bug.cgi?id=44 -- but I probably missed some case with those calculations. What are the RTTs and MSSes involved? We seem to have some extreme bandwidth * delay products here, because of how much this affects libslirp throughput (64 KiB window, which makes me think of ~2ms RTT if you get ~300mbps with, again my estimate, 1460 bytes MSS). By the way, I don't think the summary of this issue is true in general, I use pasta to connect namespaces to different remote hosts (from same data centre with microseconds RTT up to 200ms "far") and I can happily fill up gigabit links. That's not the case with the 64 KiB of libslirp. If you set ACK_INTERVAL in tcp.c to 2 (ms) I would expect that pasta will also fill up your USB sort-of-gigabit link, but that's probably low enough as to warrant one of the possible adaptive approaches I mentioned in commit 1ee2f7cada9e ("tcp: Don't reset ACK_TO_TAP_DUE on any ACK, reschedule timer as needed"). |