[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Lwip UDP performance
From: |
Christiaan Simons |
Subject: |
Re: [lwip-users] Lwip UDP performance |
Date: |
Fri, 24 Mar 2006 09:36:49 +0100 |
Aidan wrote:
> I'm using the raw api (single threaded) on a Nios2 processor runningat 50
Mhz.
> I'm having trouble getting lwip to process udp packets at a high enough
rate.
Sounds familiar, I've got similar problems ;-)
> I'm sending udp packets to the nios2 in bursts of 16+ packets (~600
bytes) at
> ~60Mbps, then leaving a break of ~40ms. The 60 Mbps is probably a
> bit too fast,
> but I would have thought that the 40ms break would give it enough
> time to catch
> up if the buffer was of a sufficient size. I've got the following
inlwipopts.h
> and I've tried increasing them with no effect:
Increasing buffers wont't improve the achievable UDP througput for small
packets.
> The behaviour I've observed is that the first 4 packets of each burst get
> processed just fine, but only a few of the remaining packets get through.
There might be a problem in your Ethernet driver.
A typical driver copies data from your chip into a pbuf-chain.
This copying might slow things down.
This is the place to look for improved performance.
Note that there may be a delay between a receive interrupt from the driver,
and the driver actually servicing the hardware.
You should try to minimize both delays. (This can be hard,
depending on the nature of the driver).
> Currently to test performance, my application increments a counter
> when it gets a
> udp packet and that's pretty much all it does, so it shouldn't be
> slowing it down
> from that end.
>
> So a few questions:
> * What kind of performance can I expect? What kind of peak performance?
This really depends on your HW and SW architecture.
> * Should lwip be able to handle 60Mbps bursts of data?
Some archs might reach full wire-speed.
> * Is lwip polled or interrupt driven. I've had a look at the code
> and looks like
> it's a bit of both... (I call lan91c111if_service(&netif); from main, the
> function is part of the driver provided for nios2.)
This is like the cs8900 driver design.
The difficualty is in reading data the within the interrupt,
this might lock-up your single threaded system (at full wire-speed).
Therefore the interrupt merely indicates the chip needs to be serviced,
and the reading is done from the infinite (main) loop.
> * Does lwip do buffer copying or is the data passed up through the stack
using
> pointers?
Some copying when needed, pointer referencing whenever possible.
This diver places the data in the same pbuf-chain as your udp receive
callback handler gets it. This is fairly efficient.
> * Is there an option to disable the udp checksum check? Or is it a case
of
> modifying the code?
I shouldn't try this.
> * Any suggestions on how to get maximum udp performance?
Try to improve your Ethernet driver.
Try to use DMA transfers, and run your lwIP stack from a thread/task
(you'll need a small RTOS) that becomes immediatly active after
the Ethernet RX interrupt.
I cannot recommend the lwip+uC/OS-II solution that Altera offers.
It is built around the lwip sequential API: low performance,
too much thread synchronisation slows it down.
Bye,
Christiaan Simons
Hardware Designer
Axon Digital Design
http://www.axon.tv