lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] lwIP performance with FreeRTOS


From: Chris Ponder
Subject: Re: [lwip-users] lwIP performance with FreeRTOS
Date: Fri, 24 Feb 2012 13:06:09 +0000

Thanks for the info, that is really helpful. I only have one thread talking to the IP stack so I have been considering using lwIP in that thread and that may speed things up.

 

I have tried adding TCPIP_CORE_LOCKING to the project pre-processor defines but it has made no difference L, I guess it is all the task switching, it just seems such a performance hit.

 

Thanks

Chris

 

From: lwip-users-bounces+address@hidden [mailto:lwip-users-bounces+address@hidden On Behalf Of Simon Goldschmidt
Sent: 24 February 2012 12:25
To: Mailing list for lwIP users
Subject: Re: [lwip-users] lwIP performance with FreeRTOS

 

Chris Ponder <address@hidden> wrote:

I then switched to the FreeRTOS version of the echo client which contains TCP and UDP tasks. I disabled the TCP task and the pretty flashing LED task and replaced the echo code with the same code I used in the standalone version but using netconn and netbuf. The performance plummeted to barely over 36Mbps, nearly one third of the standalone performance.

 

I'm assuming you used the same transfer mode (I.e. send by reference or copying the data) with both raw API and netconn API and therefore expect just a tiny overhead?

 

The traditional way of multitasking in lwIP is to pass messages between threads. This can be quite slow depending on how fast your OS implements task switches as in this mode, you typically have 2 tasks switches per send-call:

- application task calls send, prepares netbuf

- task switch to tcpip_thread, which actually sends the packet

- back to application thread, send function returns

 

Changing thread priorities doesn't change this behaviour. However, you can try TCPIP_CORE_LOCKING, which changes from thread switching to locking (using a mutex), which has the potential to be faster (again, depending on how your OS implements that and on how you use the stack, I.e. how many application threads you have). I guess it's worth a try.

 

Simon

********************************************************

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this communication is
strictly prohibited. If you have received this transmission in
error please notify the sender immediately and then delete this e-mail.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. If verification is required please request a hard copy
version.

********************************************************


reply via email to

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