There have been a number of threads about the InterNiche Lite stack and UDP missing packets. Here is what I have found. I created new thread, I hope no one minds.
The receive/transmit buffers used by the FEC are circular. This means that you need to process them in order. With an RTOS, this may not be possible so to get around this Interniche implmented a linked list queue to move them to. This alows the message to hang around until they get process without effecting the FEC.
As implemented in the DEMO, there are two FEC receiver buffer descriptors. These initially point to the first two of 8 packet buffers. The 8 are set up by the NUMBIGBUFS define and the FEC buffer descriptors is set up by the NUM_RXBDS define.
The ISR for the FEC takes 17us to process a big packet (once you fix the bugs) and up to 113us to process a small packet. the smaller packets take more time as it does a allocate and copy to try and save RAM. This means that at best case, it will take 17us to clean and release a buffer descriptor for the FEC. Since there are only two, it must clean this faster than the data comes in.
Small packet like a standard PING takes about 7us to be received by the FEC at 100M. So, if there are a number of wire speed packets in a row, whamo, you can get overflow errors.
To improve this you can increase the number of buffer descriptors. This eats into your lingering packet buffers so they may need to be increased too. Of course we only have 32K of RAM so you are very limited. You can also get rid of the "copy small packet" routine. I have found that incresing the buffer descriptors to at least three reduces my errors when receiving a stream of know bandwidth data. The extra buffer allows for the other managment packets (ping...)
I'm sure the ISR can be trimmed and thinned too to make it faster...
Just thought I would pass this on..
FlashToo
PS: be sure to fix the check for small packets bug, it should look like this in the ISR:
if ((bdp->bd_length < lilbufsiz) &&