我使用lwIP为我的系统添加网络功能。在我的平台上，我构建了一个缓冲区，我想在每次充满时发送它。这种情况很快就会发生。系统直接连接到专用LAN中的交换机。最初，数据的发送在2秒之间具有非常大的时间间隔。此外，如果我的内存正确地为我服务，数据包的大小为720字节。使用的缓冲区目前有大约20000字节的容量，我可能决定在将来增加它。网络有100兆位的速度，我希望在我的平台上接近这些速度。
当搜索速度慢的原因时，我最终得到了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并不奇怪，对吧？
我装了wirehark，看看发生了什么。
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
似乎我目前发送的东西比桌面确认更快。上面跟踪后的流量显示为黑条，看起来像：
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
答案 0 :(得分：4)
我在使用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轮询函数我基本上检查了缓冲区中有多少字节，并在轮询函数中立即用另一个样本填充它们。这是为了检查整个
我很惊讶，线鲨在大约几毫秒期间显示数据包爆发，然后 700ms无任何。
深入到堆栈中我发现，当发送65535个字节（或大致在此周围）时，发生完全。
所有这些都是通过禁用内存SANITY检查
解决的查看你的 lwipopts.h ，不管你是不是在某处定义：
#define MEMP_SANITY_CHECK 1
如果是，请删除该行或将其设置为零。因此，我的数据包发送性能没有增加（当以最大速度发送数据时，我仍然大约为11Mbits），但总吞吐量显着增加，因为两个发送数据包之间的时间现在是恒定的，大约需要100us。
需要说明的是，这仍然无法解决100MBit线路上只有11MBits完全专用于此设备的问题