c - 使用 lwIP 的原始 TCP API 时的性能问题

Question

我使用 lwIP 为我的系统添加网络功能。在我的平台上，我构建了一个缓冲区，每次它都满时我想发送它。这可能会很快发生。该系统直接连接到专用 LAN 中的交换机。最初，数据的发送在 2 秒之间有一个非常大的时间间隔。此外，如果我的记忆正确，数据包的大小为 720 字节。使用的缓冲区目前有大约 20000 字节的容量，我可能会决定在未来增加这个容量。网络有 100 mbit 的速度，我想在我的平台上接近这些速度。

在寻找速度慢的原因时，我最终选择了 lwIP 的配置。在此之前，我改变了我的发送机制。我使用原始 lwIP API，目前我将数据编写如下：

tcp_write(<pcb>, (const void*) data, <bytes>, TCP_WRITE_FLAG_COPY);
//<bytes> is at most tcp_sndbuf(<pcb>)

我知道复制标志会影响性能，但添加它是因为我不想在实际发送数据之前覆盖数据。（并且标志不是主要问题，但一旦正常工作就需要打磨）在先前的解决方案中，我省略了标志，只是等待所有字节被确认（在通过调用 tcp_output 写入后强制发送数据之后()) 通过使用回调函数。（这可能是更糟糕的性能明智，我不认为这是相关的）

我对 lwIP 中的设置进行了一些尝试，这似乎有所不同。我认为窗口大小特别有影响，尽管我不太确定。目前我显着增加了窗口大小，即使我得到了一个数据包的突发，它们之间大约有 2 毫秒（而不是 2 秒！），随后是很长一段时间的“无”，然后又是一个突发。我希望它以它应该能够达到的速度连续发送，最多应该是 100 mbit，但至少 10 mbit 并不奇怪，对吧？

我加载了wireshark，看看发生了什么。

192.168.1.26 是我运行 windows 的台式电脑。192.168.1.192 是使用 lwIP 的嵌入式系统。

最初，我从桌面向 lwIP 系统发送一个启动请求，让系统知道它应该在每次缓冲区满时开始发送缓冲区。如果相关，这是跟踪的相应部分：

5    2.007754    192.168.1.26    192.168.1.192    TCP    61    [TCP segment of a reassembled PDU]
6    2.008196    192.168.1.192    192.168.1.26    TCP    60    patrolview > afs3-fileserver [SYN] Seq=0 Win=65535 Len=0 MSS=1400
7    2.226238    192.168.1.192    192.168.1.26    TCP    60    afs3-fileserver > 50015 [ACK] Seq=1 Ack=8 Win=65528 Len=0
13    4.976858    192.168.1.192    192.168.1.26    TCP    60    patrolview > afs3-fileserver [ACK] Seq=1 Ack=1 Win=65535 Len=0
22    6.976572    192.168.1.192    192.168.1.26    TCP    60    [TCP segment of a reassembled PDU]
23    7.177903    192.168.1.26    192.168.1.192    TCP    54    50015 > afs3-fileserver [ACK] Seq=8 Ack=2 Win=64399 Len=0

我相信这没关系，尽管我不确定。无论如何，在此之后实际发送发生。相关跟踪如下开始时间是 207.992115，应该被认为是开始时间。预计与 7.177903 之间的差异：

2578    207.992115    192.168.1.192    192.168.1.26    Gryphon    1422    - Invalid -
2581    208.194336    192.168.1.26    192.168.1.192    TCP    54    afs3-fileserver > patrolview [ACK] Seq=1 Ack=1369 Win=64400 Len=0
2582    208.195880    192.168.1.192    192.168.1.26    TCP    1422    [TCP segment of a reassembled PDU]
2583    208.197035    192.168.1.192    192.168.1.26    TCP    1422    [TCP segment of a reassembled PDU]
2584    208.197134    192.168.1.26    192.168.1.192    TCP    54    afs3-fileserver > patrolview [ACK] Seq=1 Ack=4105 Win=64400 Len=0
2585    208.198712    192.168.1.192    192.168.1.26    TCP    1422    [TCP segment of a reassembled PDU]
2586    208.199867    192.168.1.192    192.168.1.26    TCP    1422    [TCP segment of a reassembled PDU]
2587    208.199965    192.168.1.26    192.168.1.192    TCP    54    afs3-fileserver > patrolview [ACK] Seq=1 Ack=6841 Win=64400 Len=0
2588    208.200927    192.168.1.192    192.168.1.26    TCP    1314    [TCP segment of a reassembled PDU]
2590    208.397469    192.168.1.26    192.168.1.192    TCP    54    afs3-fileserver > patrolview [ACK] Seq=1 Ack=8101 Win=63140 Len=0

看来我目前发送的东西比桌面 ACKing 更快。上述跟踪后的流量显示为黑条，如下所示：

2591    208.399051    192.168.1.192    192.168.1.26    TCP    1422    [TCP Previous segment lost] [TCP segment of a reassembled PDU]
2592    208.399136    192.168.1.26    192.168.1.192    TCP    54    [TCP Dup ACK 2590#1] afs3-fileserver > patrolview [ACK] Seq=1 Ack=8101 Win=63140 Len=0
2593    208.400208    192.168.1.192    192.168.1.26    Gryphon    1422   
2594    208.400285    192.168.1.26    192.168.1.192    TCP    54    [TCP Dup ACK 2590#2] afs3-fileserver > patrolview [ACK] Seq=1 Ack=8101 Win=63140 Len=0
2595    208.401361    192.168.1.192    192.168.1.26    Gryphon    1422    - Invalid -
2596    208.401445    192.168.1.26    192.168.1.192    TCP    54    [TCP Dup ACK 2590#3] afs3-fileserver > patrolview [ACK] Seq=1 Ack=8101 Win=63140 Len=0
2597    208.402425    192.168.1.192    192.168.1.26    Gryphon    1314   
2598    208.402516    192.168.1.26    192.168.1.192    TCP    54    [TCP Dup ACK 2590#4] afs3-fileserver > patrolview [ACK] Seq=1 Ack=8101 Win=63140 Len=0
2599    208.403588    192.168.1.192    192.168.1.26    Gryphon    1422    [TCP Fast Retransmission] Command response
2600    208.403685    192.168.1.26    192.168.1.192    TCP    54    afs3-fileserver > patrolview [ACK] Seq=1 Ack=14833 Win=64400 Len=0
2605    209.992237    192.168.1.192    192.168.1.26    Gryphon    1422    - Invalid -
2607    210.200219    192.168.1.26    192.168.1.192    TCP    54    afs3-fileserver > patrolview [ACK] Seq=1 Ack=16201 Win=63032 Len=0
2608    210.201819    192.168.1.192    192.168.1.26    Gryphon    1422    [TCP Previous segment lost] - Invalid -
2609    210.201903    192.168.1.26    192.168.1.192    TCP    54    [TCP Dup ACK 2607#1] afs3-fileserver > patrolview [ACK] Seq=1 Ack=16201 Win=63032 Len=0
2609    210.201903    192.168.1.26    192.168.1.192    TCP    54    [TCP Dup ACK 2607#1] afs3-fileserver > patrolview [ACK] Seq=1 Ack=16201 Win=63032 Len=0
2611    210.203070    192.168.1.26    192.168.1.192    TCP    54    [TCP Dup ACK 2607#2] afs3-fileserver > patrolview [ACK] Seq=1 Ack=16201 Win=63032 Len=0
2955    345.001223    192.168.1.192    192.168.1.26    Gryphon    1422    [TCP Retransmission]

现在在这一点之后有一个我无法解释的巨大延迟。下一个数据包在 345 秒到达，这是 135 秒的差异。（虽然在大多数情况下它有点少，但仍然太高了）它开始如下：

2955    345.001223    192.168.1.192    192.168.1.26    Gryphon    1422    [TCP Retransmission]
2958    345.001707    192.168.1.26    192.168.1.192    TCP    54    afs3-fileserver > patrolview [ACK] Seq=1 Ack=20305 Win=64400 Len=0
2959    345.003336    192.168.1.192    192.168.1.26    TCP    1422    [TCP segment of a reassembled PDU]
2960    345.004395    192.168.1.192    192.168.1.26    TCP    1314    [TCP segment of a reassembled PDU]
2961    345.004494    192.168.1.26    192.168.1.192    TCP    54    afs3-fileserver > patrolview [ACK] Seq=1 Ack=22933 Win=64400 Len=0

等等

后来虽然提到的延迟更短，但也会出现类似的问题。我的问题是：如何解决从我的平台发送缓慢的问题，我应该如何配置我的 lwIP 设置以获得体面/良好的结果？我想快速发送数据。（我的网络能够达到 100Mbps，越接近越好）我认为我目前完全搞砸了我的设置，但我不确定如何根据我的需要对其进行微调。以下是我的 lwipopts.h 中的一些（希望如此）相关设置

文件：

#define MEM_SIZE                        65000
#define PBUF_POOL_SIZE                  1024
#define IP_FRAG_USES_STATIC_BUF         0
#define TCP_WND                         65535
#define TCP_MSS                         1400
#define TCP_SND_BUF                     65535
#define PBUF_POOL_BUFSIZE               LWIP_MEM_ALIGN_SIZE(1528)
#define LWIP_TCP_KEEPALIVE              1
#define LWIP_SO_RCVTIMEO                1

score 4 · Accepted Answer

我使用 beaglebone 和以下设置遇到了类似的问题

#define MEM_SIZE                        (1024 * 1024) /* 1MiB */
#define MEMP_NUM_PBUF                   1024
#define MEMP_NUM_TCP_PCB                32
#define PBUF_POOL_SIZE                  1024
#define TCP_MSS                         1460
#define TCP_WND                         (4*TCP_MSS)
#define TCP_SND_BUF                     65535
#define TCP_OVERSIZE                    TCP_MSS
#define TCP_SND_QUEUELEN                512
#define MEMP_NUM_TCP_SEG                512

使用 tcp_sent 轮询函数，我基本上检查了缓冲区中有多少字节，并立即用另一个样本将它们填充到轮询函数本身中。这是为了检查整个

我很惊讶线鲨在大约几毫秒内显示了数据包的爆发，然后在 700 毫秒内什么也没有。

深入我发现的堆栈，这恰好发生在发送 65535 个字节的那一刻（或大约在这个附近）。

通过禁用内存健全检查解决了所有问题

查看您的lwipopts.h，是否偶然您没有在某处定义：

#define MEMP_SANITY_CHECK 1

如果是这样，请删除该行或将其设置为零。因此，我的数据包发送性能没有提高（以最大速度发送数据时我仍然在 11Mbits 左右），但总吞吐量显着增加，因为两个发送数据包之间的时间现在是恒定的并且大约需要 100us。

需要说明的是，这仍然没有解决 100MBit 线路上只有 11MBits 完全专用于该设备的问题

c - 使用 lwIP 的原始 TCP API 时的性能问题

1 回答 1

Related

Reference