Re: [lwip-users] Dynamic page updation using Ajax-Issue

2016-09-21 Thread Noam Weissman
Hi, 384K of RAM is a lot. I run a WEB server on a micro with 96K when only 8K was for LwIP. Do you have sufficient PCB's defined for multiple connections ?... Are you using RAW API ?... Server code is your own or based on something from the net ? BR, Noam. -Original Message- From:

[lwip-users] Dynamic page updation using Ajax-Issue

2016-09-21 Thread ece.kishor
I am developing an embedded web server using lwip. My requirement is to dynamically update the value in browser without refreshing the whole web page. I am using a processor from atmel named SAME70Q21 having onboard RAM of 384 KB. When the server is live and running, when multiple number of PCs’

Re: [lwip-users] Problem with freeing tcp segments

2016-09-21 Thread Sergio R. Caprile
Your picture of the threads running suggests you are using some form of an OS... have you tested the port with a known good application so you know for sure that everything is running fine ? If so, in what part of memp_overflow_check_element_overflow() you see the loop and how is it occurring

Re: [lwip-users] Dynamic page updation using Ajax-Issue

2016-09-21 Thread Noam Weissman
Dear, I know what is AJAX and how it works … you did not answer my questions? BR, Noam. From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On Behalf Of Erkan Ersoy Sent: Wednesday, September 21, 2016 4:52 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] Dynamic

Re: [lwip-users] Dynamic page updation using Ajax-Issue

2016-09-21 Thread Sergio R. Caprile
> I am developing an embedded web server using lwip. [...] > When the server is live and running, when multiple number of PCs’ > give web requests, server fails to respond. > Is their any solutions for fix this problem? yes, fix your web server... ;^) Are we understanding each other ? I mean,

Re: [lwip-users] Netconn vs. raw API performance

2016-09-21 Thread Sergio R. Caprile
Netconn has more overhead than the RAW API. In scenarios where the eth pipe is faster than the micro, this extra overhead means extra latency and so less thruput. However, 2 seconds rtt is, how can I say it, a bit way too much ? Having "problems" with more than 128 bytes per message is another