Why I have to increase MAXBIGPKTS to make the UDP transfer

[Altera_Forum]

Hello everyone,  

 I am now doing a data transfer work based on StratixII NiosII development kit RoHS board. It is a very simple one which read data from a FIFO outside NiosII core. The data are sent to computer through on-board Ethernet LAN91C111 by UDP protocol.  The data transfer cycle is as this: read data from FIFO -> store in DRAM -> transfer to computer. The package size of UDP is 1468 Bytes. The problem is, when I use default MAXBIGPKTS value (30) in ipport.h, it will give me errors (error# is 105 which said I do not have enough buffer) after few cycles. I have to increase MAXBIGPKTS value to 3500 to eliminate the error but the memory and performance are suffered due to this.  My niosII cpu core run at 150Mhz speed with data and instruction cache size both 64KB. Now the UDP transfer rate is about 22Mbits/s. According to others design (such as Ethernet_Accel_Design by Altera), they really don't need to increase MAXBIGPKTS value. Do you have any suggestion for me? Thank you very much.   Xishan  p.s. I am now using Quartus II 9.1sp1.

[Altera_Forum]

does anybody have experience on UDP for large amount data transfer?

[Altera_Forum]

I don't but if it can help, some IP seem relevant for high rate UDP transfers. 

example on "alse" website : alse-fr.com/archive/GEDEK_Intro.pdf Good luck !

[Altera_Forum]

Unfortunately the transfer rate is strongly limited by the CPU and its access to the LAN chip. You can try and use faster memory for the packets data (on-chip memory) but you will be limited compared to accelerated designs with the TSE.

[Altera_Forum]

Hi Daixiwen,  

 Actually I have tried to use TSE daughter board along with this development kit. I met the same problem. It is very strange that the accelerated design from Altera works well so I think there must be something wrong in my design.   I also tried to use onchip memory but got no luck. I guess that I send the socket packets to the Ethernet port too fast. The Ethernet port cannot empty the buffer in time if the allowed buffer number size (MAXBIGPKTS) is a small value. Is there a way that I can improve that? I saw a lot of people can achieve above 50Mbits/s speed without change anything related to the default buffer value.   Thanks for you help.  Xishan

[Altera_Forum]

No the problem is in fact the other way round. The TCP/IP stack waits until a packet has been sent before preparing a new one, so you won't run out of buffers when sending a lot of UDP packets. It will just be slower. 

On the receive side, it is another story. Each time an ethernet packet arrives, the LAN chip wakes up the CPU and call an interrupt routine. This routine will then allocate one buffer from the pool and put the data in it. Then the TCP/IP stack will wake up, read and process the packet contents, and frees the buffer. If the Nios system is receiving more packets that it can handle (either because the incoming bitrate is too high or because the CPU is too busy doing something else) then you will run out of buffers. So what you must check is: 

• What kind of packets are transmitted to your NIOS system? From what you are telling you are mostly sending packets, so it's strange that you are receiving so many packets. You can use a software such as Wireshark on your PC to see all the packets that are received/transmitted 
• Do you have high priority tasks that eat all your CPU power, leaving not enough cycles to receive packets properly?

[Altera_Forum]

Hi Daixiwen, 

 Thanks for your replay.   Yes I am only sending data by UDP. The network traffic jams when I send data repeatedly.   Now the priority for data read and network transfer is 4. I will change the priority to see if there is any improvement.   Xishan

[Altera_Forum]

Hello Xishan, 

 i am not come up with solution ...rather i am struggeling with same problem. i am not able to receive more then 1464 charactor through UDP based client server application ....my server (on linux machine ) send's 7 packet of UDP data each having 1464 charactor but my client (nios-II) won't accept more then one packet.... my application stack size is 1024,  could you please help me out  kaushal   --- Quote Start ---  Hello everyone,   I am now doing a data transfer work based on StratixII NiosII development kit RoHS board. It is a very simple one which read data from a FIFO outside NiosII core. The data are sent to computer through on-board Ethernet LAN91C111 by UDP protocol.  The data transfer cycle is as this: read data from FIFO -> store in DRAM -> transfer to computer. The package size of UDP is 1468 Bytes. The problem is, when I use default MAXBIGPKTS value (30) in ipport.h, it will give me errors (error# is 105 which said I do not have enough buffer) after few cycles. I have to increase MAXBIGPKTS value to 3500 to eliminate the error but the memory and performance are suffered due to this.  My niosII cpu core run at 150Mhz speed with data and instruction cache size both 64KB. Now the UDP transfer rate is about 22Mbits/s. According to others design (such as Ethernet_Accel_Design by Altera), they really don't need to increase MAXBIGPKTS value. Do you have any suggestion for me? Thank you very much.   Xishan  p.s. I am now using Quartus II 9.1sp1.  --- Quote End ---  

[Altera_Forum]

Did you correct the problem shown by dsl in this message (http://www.alteraforum.com/forum/showpost.php?p=88265&postcount=2)?

[Altera_Forum]

Hello there, 

 Actueally server is sending 10 UDP packet each having packet size of 1464. server is based on linux machine having RHEL-4 installed. whereas client is on nios-II board,  now problem is, server is sending 10 UDP packet whereas client received and display only 1 UDP packet (size 1464). why remaning 9 packet won't received by client.  kaushal

[Altera_Forum]

I understand your problem description. But in the last code you shown us, the buffer space isn't allocated, as dsl told you. In this case when you receive the first packet, its contents are written in a space that wasn't meant for that and is probably used by something else. This can trigger all kind of weird bugs.