Re: [lwip-devel] STM32, FreeRTOS and lwIP - Timeout problems

[Rüdiger Asche]

ok, here's another issue you may look into: Your ETH controller will
maintain a number of receive buffers. Depending on what code you used
to model your driver on, there will most probably be something along
the lines of

DmaRxBufs[RXBUFS];

This constant number (RXBUFS) is actually a crucial bottleneck. he
control flow is typically as follows: DMA copies data (either
broadcast packets or packets directed to the MAC address you program
into your controller) to those packets, but only as longs as the
packets are owned by the DMA (indicated by a flag in the buffer's
descriptor). An IRQ will be generated that normally just wakes up a
high pri task which copies the data to pbus allocated dynamically,
then return the buffer to the DMA and informs lwip of the recieved
packet via a mailbox.

If your RXBUFS count is small (<= 5) AND that there are many
broadcasts in the net, chances are that the broadcasts eat up all
available buffers before a packet directed to your stack has a chance
to be processed by your unit. If you have sufficient RAM available,
try for testing to raise the number to, say, 20. My prediction is that
your successful connection rate will be much higher.

It's a case of which death you die; either your TCP stack starves due
to a limited number of receive buffers or the rest of your system
starves from too little RAM because you have to set aside to much
static RAM for receive buffers. Worse even: If it works fine in the
network at your development side, chances are that in a customer's net
there may be broadcast storms (some network management systems are
brutal in the numbers of broadcasts they send around in the net) that
may raise the problem again and again no matter how high you set the
buffer rate. I've seen it all.

It's a typical pifall in the embedded world; everybody expects the
processors to be as performant as a PC. They aren't. PCs have tons of
RAM and virtual RAM, so you can buffer a lot of network data and
eventually get to processing every true payload packet - worst case it
slows down the communication. On top of that, PC processors are
clocked at least 15 times faster than typical embedded controllers, so
the time it takes a PC to release a network buffer is much smaller, so
the turnaround is faster.

There are other issues; for example, you are ok as long as your unit
acts as a TCP client. If it acts as a TCP server - eg a Web server -
you run into more problems because TCP keeps connections open 120
seconds after they are closed (TIME WAIT issue), and a typical Web
interaction opens and closed several logical connections in rapid
succession, so your Web server may actually eat up all the available
RAM during the time all connections are held open!


2013/1/8, Rüdiger Asche <address@hidden>:
> so is your application a tcp server or a tcp client? Since you write
> about timeouts, I assume it is a tcp client, and an attempt to
> connect() returns with -1 and the error set to ETIMEOUT? It would help
> if you installed a sniffer (eg wireshark) and logged the packet flow;
> that would at least narrow down the problem.
>
> What kind of TCP server do you communicate against? Bear in mind that
> a timeout may also imply that the server is not able to service the
> request! This happens frequently, for example when the TCP Server is
> single threaded meaning that it services a client request without
> spawning a new thread. When that happens, other TCP clients will first
> end up in a queue, and when the queue overflows, nothing happens on
> the net (one of those brain dead details of TCP practice). So a busy
> server might as well the problem. Again, a sniffer trace would help
> narrowing down the problem.
>
> 2013/1/8, Thomas Kølbæk Jespersen <address@hidden>:
>> Thank you for your comments on this issue.
>> I have been searching closely on this forum to see if could find anything
>> related to this issue, without luck.
>>
>> I found this thread yesterday and have tried all the steps they recommend
>> but it didn't solve the problem with the timeouts:
>> http://www.freertos.org/FreeRTOS_Support_Forum_Archive/October_2011/freertos_Random_hangs_with_STM32_4753773.html
>>
>> I have been struggling so much with this issue by now that I am willing
>> to
>> pay anybody with exprience within the STM32, FreeRTOS and lwIP field, to
>> get my already made project and source code working.
>> Please have a look at this Freelancer post with some more details about
>> the
>> issue:
>> https://www.freelancer.com/projects/Electronics-Microcontroller/STM-Ethernet-lwIP-FreeRTOS-FatFS.html
>>
>> Kind Regards
>> Thomas Jespersen
>>
>