[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Lwip slow received data speed

From: Keith Rubow
Subject: Re: [lwip-users] Lwip slow received data speed
Date: Tue, 17 Apr 2018 15:36:21 -0700
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

For anyone interested, I solved my slow data transfer problem when receiving large amounts of data. Increasing PBUF_POOL_SIZE didn't fix the problem, but it did make the data reception speed up for a little while when I first started sending data. Then it would slow down, and stay slow forever, even if I stopped sending data and then started again. So it felt like a pbuf related issue.

My tcp receive data callback was saving a pointer the the pbuf for later processing, or using pbuf_chain() to chain the pbuf(s) to the end of the currently queued data if I already had some data in my queue. Later background processing took data out of the queued pbufs and would pbuf_free() each pbuf as it was emptied.

The problem was that pbuf_chain() incremented the ref count of the chained pbufs, so when I later called pbuf_free() they were not being freed. The ref count was decremented, but those pbufs were not free, and became permanently unavailable for use. I was running out of pbufs! I changed pbuf_chain() to pbuf_cat() in my tcp receive callback, and everything works perfectly.

Keith Rubow

On 4/15/2018 11:30 AM, Sergio R. Caprile wrote:
My best guess for a Sunday is that you are missing frames while you are
busy writing your flash.
Your Ethernet chip can only hold a limited number of frames and if you
don't empty it frequently enough, or your driver runs out of pbufs to
store incoming frames, you'll lose them.
Try to enable breakpoints on key places, enable statistics, I like to
move pins when entering and exiting critical regions and watch the flow
on a Logic Analyzer (cheap USB).

lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]