转自老衲五木的新浪博客
一个网友遇到的问题，ping设备的时候，时间会越来越长，从几毫秒到几百毫秒，有时候甚至无ping响应。这里的原因在于，他使用了中断的方式接收网卡数据包，在每次中断中只读取网卡的一个数据包。如果一次中断发生，而网卡内事实上可能存在有多个数据包，这样如果只读一个，最终导致网卡内数据包积压，所以会出现ping延迟的现象。如果数据包长期积压，还可能出现因网卡缓冲区满而无法接收数据的情况，由于无接收中断产生，控制器也不会处理积压数据的现象，从而发生网卡假死的现象，系统无法接收数据。
这里的正确解决方法是，在一个中断中，需要读取并处理所有的已经接收的数据包。网友的ping延时问题通过这种方案已经得到解决。 下面是以前一个论坛关于这个话题的讨论，他们的发生原因与解决方案与上述相同： [lwip-users] Slow ping response times On 11/13/2012 10:04 AM, Louis Wells wrote:Hello, I just finished porting lwip to my hardware(lcp2468), and after running some initial tests just pinging the board I have ran into an issue. The first batch of pings I send are usually replied to in a reasonable time(<5 ms), however as I continue to ping the board the response time gets worse and worse. I watched the activity on wireshark, and determined that the board is still responding, it is just taking up to 12 seconds to do so.
I ran a trace on the board, and it appears that there is not an issue where it is receiving packets too quickly to process them, as I can see it hitting the ISR when the packet is received, moving the packet into the mailbox, and running tcpip_input followed by ip_input before another packet is received.
I am not sure where to even begin looking for a way to solve this. A little information about my implementation is that I am using this with freertos, I have 1 thread set up for the main tcpip thread, and one thread that handles inputs whenever the emac ISR wakes it.
If there is anything that I can provide that might give someone some insight please let me know, and thanks in advance for any help.
Louis On Tue, Nov 13, 2012 at 12:00 PM, 醉熏的雪糕 Lakata <<a rel="external nofollow" href="mailto:address@hidden" rel="nofollow" target="_blank">address@hidden> wrote: I'm not sure about the LCP demo code, but the ST demo code for LWIP had a poor implementation where the incoming messages were not being read out correctly from the ethernet hardware FIFO. It assumed one interrupt per message, but if you delay servicing the ISR for a brief time, you may have 2 (or more) messages and only 1 interrupt.
Make sure your input loop drains all ethernet packets, and not just one. And/or make sure your ISR drains the hardware FIFO on each interrupt -- don't just grab one packet.
The code kinda/sorta works like you said (with long delays) because new incoming traffic eventually pushes the backed-up messages through the FIFO. But it gets worse and worse with time as the FIFO gets backed up.
-醉熏的雪糕
Thanks a ton that completely fixed it. What you were describing is exactly what was happening, so I added a loop to my input function to continue processing packets until the produce index == the consume index.
pings are now consistently 4-5ms. thanks again ! Louis