mirror of
https://github.com/ipxe/ipxe
synced 2026-01-21 01:28:02 +03:00
a8c89276cc
Commit 2d180ce ("[tcp] Update maximum window size to 2MB") increased
the TCP window size to avoid filling the TCP window on typical modern
links.
The total heap size is only 512kB. Given that RX I/O buffers are
typically subject to alignment constraints, it is plausible that we
may be able to actually buffer only 256kB of data before having to
discard queued out-of-order packets.
On a low latency network, this behaviour is not a problem: the sender
will rapidly retransmit the lost or discarded packets. On a high
latency network, the sender's congestion control algorithm will end up
calculating a congestion window that is substantially smaller than our
advertised 2MB, which will result in a drastic reduction in actual
throughput.
We do not want to increase the heap size arbitrarily, since we still
have the constraint that memory used by iPXE may be permanently lost
to the operating system (depending on how the operating system is
booted). However, the cost of keeping the heap size down to 512kB is
no longer acceptable given that large downloads over high-speed
wide-area networks are now routine.
Increase the heap size from 512kB to 4MB. This should be sufficient
to hold an entire 2MB TCP window for a single connection under most
sensible conditions. For example:
* 1460-byte MSS => 1436 packets => 2872kB of 2kB RX I/O buffers
* 8960-byte MSS => 234 packets => 3744kB of 16kB RX I/O buffers
The notable exception is that of a network where jumbo frames are in
use, but the TCP connection ends up using a standard 1460-byte MSS.
If this is found to be an issue in practice, then one possible
solution would be to shrink (or reallocate) I/O buffers for
out-of-order queued data.
Experimentation shows that before this change, an induced latency of
25ms (representative of a typical connection to a public cloud
provider) would cause the download speed to vary unpredictably between
2MB/s and 25MB/s. After this change, the speed in this test scenario
remains consistently high at 25MB/s.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE README File Quick start guide: cd src make For any more detailed instructions, see http://ipxe.org