Data size can't be 2MB/s, by data size I mean the size of the data
chunks you are handling in each frame, you expect to handle an amount of
data in a period of time, and that data is handled in pieces, if pieces
are too short you need to handle many pieces, if pieces are too long,
you need more room to handle them. Those pieces are of xxx bytes, where
xxx = ? You should probably get more performance out of longer pieces.
Those pieces are staying somewhere before they are sent back. There is
no reason for them to stay "inside lwIP" unless you are not getting them
out in due time.
Are they being queued on receive ?
Are they being queued on transmit ?
Is your application called fast enough by your OS ?
Is the interface serviced fast enough by your OS ?
Are priorities getting things worse ?
I would start by measuring the number of frames in a certain time, and
seeing why they are queuing somewhere; how much time they spend in each
stage (in rx queue, in your application, in tx queue). That may need you
to add instrumentation to the piece of code where frames are received
and sent by lwIP, and of course by your application.
As stated before:
The amount of memory used depends on your application. There is no
reason to queue UDP datagrams unless you don't get them as they come.
And avise again:
If you are expecting high-performance, you should be using RAW API, and
so each received frame carrying a UDP datagram would trigger a callback
to your application receive function.
lwip-users mailing list