lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] BasicWeb.c behavior


From: Bill Auerbach
Subject: RE: [lwip-users] BasicWeb.c behavior
Date: Fri, 8 Feb 2008 14:33:42 -0500

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf
> Of BMW Cyclist RR
> Sent: Friday, February 08, 2008 1:50 PM
> To: address@hidden
> Subject: [lwip-users] BasicWeb.c behavior
> 
> I am running lwip v1.2.0 with FreeRTOS 4.2.1 on a AT91SAM7X-EK board with
> an
> X512 chip. I have been actively adding UDP and TCP application programs
> with
> only minor issues, but when trying to resolve a resource (memory) issue
> I've
> dropped back to running just the standard BasicWeb.c webserver so I could
> better understand what the lwipopts.h values actually do in terms of TCP
> internal data structures. I am able to do source level debugging with
> Eclipse and the Amontec JTAGKEY along with OpenOCD.
> 
> What I've noticed when running just the Webserver application with my
> other
> tasks disabled (all other FreeRTOS tasks are not created) is that the
> lwip_stats.memp[3] statistics show that the number of TCP_PCBs used seems
> to
> keep getting bumped everytime the webserver returns a webpage. I've got
> MEMP_NUM_TCP_PCB set to 10 (in lwipopts.h) and I see that memp[3].used and
> memp[3].max keep climbing with each web browser connection until the limit
> of 10 is reached. Then I see memp[3].err get incremented while the
> memp[3].used and memp[3].max stay at 10. The webserver continues to
> operate,
> seemingly normally. Is this due to previous TCP connections (i.e..
> webserver) hanging around for a while and continuing to tie up TCP_PCBs?

I can confirm this with 1.3RC? (last week's Update).  I didn't notice this
since I could refresh dozens of time without an error, but you are correct,
the used PCBs max out at the maximum and the err count keeps incrementing.

Bill Auerbach





reply via email to

[Prev in Thread] Current Thread [Next in Thread]