[Top][All Lists]

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

Re: [lwip-users] LWIP UDP throughput with Iperf

From: Sergio R. Caprile
Subject: Re: [lwip-users] LWIP UDP throughput with Iperf
Date: Fri, 16 Sep 2016 10:58:51 -0300
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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.

reply via email to

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