Altera TSE driver and example program for lwIP (1.3.2)

--- Quote Start ---

lwipopts.h is not optimized and close to the shipped opts.h. One set of settings for one person's idea of fast might not be for another's. Or might take up more resources than is available. There are many posts on the lwip forum (at savannah.org) about "optimum" options. On a NIOS II system with gobs of RAM, I hike TCP_WND, and allow 1000's of packet buffers. Also allow more pending packets (MEMP_NUM_TCP_SEG) and use a full MSS. Unfortunately one of the limits in speed is the Altera driver which is partly why Interniche is dead slow (and dies with any kind of packet flood).

--- Quote End ---

Is Interniche so bad idea ? My idea was to buy it when the lwIP would not be an option (due to performance).

--- Quote Start ---

TCP writing is faster than reading. You should get close to 100Mpbs in both directions with "good" lwip options. I use Gig and it's OK on sending but has trouble with high speed receiving - I'm still trying to get a hardware update to get flow control working. My high bandwidth stuff is using UDP and 500Mbps outbound is easily possible. My TCP app with large amounts of inbound TCP isn't so critical but needs to be 40Mbps or so which was not a problem.

--- Quote End ---

I wonder how you can achieve this :) maybe i am doing something wrong, probably it is the timers problem (i'm using the implementation from your example for lwIP 1.3) , i should have a look at the timers implementation introduced in lwIP 1.4

--- Quote Start ---

I use RAW API in lwIP and that's a huge speed advantage over netconn or worse, sockets. It all depends on what you need for the API.

--- Quote End ---

Me too, no OS so RAW API used

--- Quote Start ---

Somewhere I posted the 10 or 12 best things you can do to improve performance. Note that in lwIP 1.4.x a couple of the speed improvements came from patches submitted by me (notable inline IP checksumming). 1.4.x is definitely better than 1.3.x which this example is based on. I recommend using the latest lwIP release.

Hope this helps,

Bill

--- Quote End ---

I'm already using lwIP 1.4 , could please point me to the differences in the example between lwIP versions ?

Thank You

--- Quote Start ---

Is Interniche so bad idea ? My idea was to buy it when the lwIP would not be an option (due to performance).

--- Quote End ---

The opposite is true - you will switch back to lwIP if you try InterNiche because it is slower. It is also less robust - I can easily lock it up where I can't lock up lwIP doing the same test.

--- Quote Start ---

I wonder how you can achieve this :) maybe i am doing something wrong, probably it is the timers problem

--- Quote End ---

I couldn't do this at first, although for my first year with lwIP it was on a 533MHz PowerPC embedded system and it could do the full link speed with TCP. I didn't hit performance problems until the NIOS II. I needed 240Mpbs with TCP and was unable to achieve that but with UDP I could do 800Mpbs. But along the way we added TCP/UDP checksumming in hardware. That would have helped TCP but I knew it wouldn't be enough still. I spent 2 months optimizing lwIP - the drivers (SGDMA, TSE and PHY are mostly rewritten and memcpy is my own in assembly language). Plus a lot of experimenting. That's where the aforementioned list came from.

--- Quote Start ---

(i'm using the implementation from your example for lwIP 1.3) , i should have a look at the timers implementation introduced in lwIP 1.4

--- Quote End ---

I don't use them - I use something similar to this example but used with an OS (but I use NO_SYS=1).

--- Quote Start ---

Me too, no OS so RAW API used

--- Quote End ---

I use a cooperative OS (written myself) - you almost have to use an OS to keep TCP/IP happy in the background while having your application run in the foreground. My system is event and ISR driven so TCP/IP gets all the CPU time outside of events and interrupts.

--- Quote Start ---

I'm already using lwIP 1.4 , could please point me to the differences in the example between lwIP versions ?

--- Quote End ---

That's good. You have to optimize until you see speeds you can live with.

Bill

--- Quote Start ---

Definitely see: http://www.alteraforum.com/forum/showpost.php?p=100193&postcount=37

--- Quote End ---

+1 These recommendations are VERY helpful.

Hey guys,

i got a error using this example.

i build my example and run it one hardware (iniche sss example runs well). I get following Output.

Running...

Waiting for link...OK

Waiting for DHCP IP address...IP address: 192.168.221.130

Why i dont get any informations about the PHY like the example shows?

i use another phy chip then Marvel PHY 88E1119 i think marvell 88E1111. Something to do with that ?

I can also ping my board now and can connect to the http server in the browser but im wondering why i cant get this informations.

thanks for help.

Rene

--- Quote Start ---

Hey guys,

Why i dont get any informations about the PHY like the example shows?

Rene

--- Quote End ---

Rene, PHY is managed by altera_avalon_tse.c, not by lwip. To enable debug output compile your BSP with -dALT_DEBUG.

hey ims,

thx for this

i got now an other prob i tried to make my own example with tcp and exclude the http files and make my own tcp files. I can connect and i can receive data over port 7 TCP but when i try to make pbuf_free() after the receive tcp_recevd i get the error

Assertion "pbuf_free: p->ref > 0" failed

In the web i read it has to do with multiple acces on pbuf the file lwip_tse_mac.c access to this to is there the problem and why this error doenst occure when i use the http example from here.

thanks Rene

--- Quote Start ---

i got now an other prob i tried to make my own example with tcp and exclude the http files and make my own tcp files. I can connect and i can receive data over port 7 TCP but when i try to make pbuf_free() after the receive tcp_recevd i get the error

--- Quote End ---

Rene, Your Receive_cbf() must return 0. See doc/rawapi.txt. Igor

Thanks ims it works. Im very thankfull for your support and thanks BillA for this great example.

Rene

You're welcome. And be sure to apply this change which works around a bug in the Altera SGDMA which I missed in the original driver (nor have I seen to date in 5 NIOS II applications): http://www.alteraforum.com/forum/showpost.php?p=146506&postcount=164

Bill