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

[Keith Rubow]

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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users