TM4C129 Ethernet client: http request loss when receiving continuous inquiries

[guy8247 1]

Dear oh43 users,

I am facing trouble on an application providing on a webserver serving html documents and images from a SD card and running on a EK-TM4C1294XL platform.

 

Currently, I am bypassing the SD card storage and all the binary and html code are embedded in the source code.

 

The configuration is now quite simple, where the webserver is supplying an index.htm page and several jpeg images referred in this page.

 

For this this test purpose, and in order to increase the network traffic several jpeg image filenames are specified in the source code like tiger1.jpg, tiger.jpg, etc (total 10 images) therefore the webserver provide every time the same binary image stored into tiger_jpg array (defined in tiger.h).

 

Every time, the index.htm page and some of the images are loaded successfully (see screen capture in attachment). However, some images aren

tiger.h

log 2014-09-03 16h00 console msg about lost of receiving http request.txt

CAP 2014-09-03 16h00 network capture lost of http request.zip

[spirilis 1,265]

I do believe the Ethernet library for Energia limits lwIP to 8 concurrent connections, so that may account for your limitations.  How many pics usually show up?

[David Bender 28]

Why don't you try setting the Connection:close header on the tiger request?

[spirilis 1,265]

Specifically, hardware/lm4f/libraries/Ethernet/EthernetServer.h:

#define MAX_CLIENTS 8

Try tuning that a bit and see if it helps.

[Rickta59 589]

Old browsers never used to open more than 2 concurrent connections to a server. Modern browsers will open up a boat load of concurrent socket connections. To see what is going on, use chrome and turn on the developer tools. Then reload and inspect your pages network resource usage and the timeline. In the timeline it displays all the concurrent connections attempting to download all your images at the same time. This works great for a webserver that expects more than 10k concurrent connections and is connected via giga-ethernet. Not so good for you.

 

The best web server content is the kind you don't serve more than once. You should look at adding HTTP cache headers to your response.

 

You can try slow loading your images driving the process with javascript, instead of using image tags.

 

You could try changing the max-persistent connections per server in your browser.

 

You could respond with HTTP/1.0 protocol header and the Connection: close as @ David Bender suggested.

 

Me personally, I think these connected devices work best as outbound only devices shipping their content to some other server capable of acting as a true webhost.

 

-rick

[guy8247 1]

Thanks everyone for your comment, and please find latest results based on your suggestions.

 

@@spirilis, increasing MAX_CLIENTS 8 to value 16 didn

[spirilis 1,265]

Well without looking too deeply, it's probable that the Ethernet library and your sketch just can't keep up... or maybe some RX buffer tunables could be adjusted here either in Ethernet or lwIP.  I haven't looked yet to see what they are.

 

But I think it underscores @@Rickta59 's point, these things aren't really meant to be high-performance webservers.  They do a pretty good job for what they are IMO.  Perhaps a TCP/IP-oriented RTOS could manage things better for this application.

[guy8247 1]

spirilis,

 

Thanks for your feedback, currently I follow the Rickta59's recommandation and I am using an external server supplying the image files. The TM4C129 platform provides only the html pages from an SD card and the performance are much higher and stable.

[spirilis 1,265]

spirilis,

 

Thanks for your feedback, currently I follow the Rickta59's recommandation and I am using an external server supplying the image files. The TM4C129 platform provides only the html pages from an SD card and the performance are much higher and stable.

Np, that should work ... Heck we often do a similar thing in larger webserving installations, with a "web tier" serving static content directly and certain paths for dynamic data internally redirected to an "application tier".

 

Side note- TI's new CC3100/CC3200 series WiFi chipsets/MCUs have a webserver feature built into the WiFi network processor, possibly to address this concern (although I'm not sure if its performance is up to par for the kind of rapid-fire image loading you're doing here).  But same idea--static content from the CC31xx wifi processor, dynamic content comes from the main MCU.

[David Bender 28]

You probably can get decent web performance with the TM4C129. You can't use a naive web server though. I've written an embedded web server for my client (on an ARM chip as well) and can recommend the following:

 

1) Don't buffer the client request; try to parse the request as the data comes in. 98% of your requests are GETs and do not require buffering. Consequently you can boost the number of sockets you can process at a time.

2) I recommended trying Connection: close because I thought the browser may have been trying to reuse the socket and your code didn't seem to support that. Connection: close is BAD precisely because the client will use more socket resources. So try to reuse the socket.

3) Send etags back on all GETs and parse etags from the client. 304 responses take way less bandwidth.

4) I'm not sure what client.write() does, but it does not seem to distinguish between RAM and flash. LWIP can operate way more efficiently if it does not have to make a second copy of the data.

5) Though you can \n as a line terminator, just send \r\n. Do it.

6) Be nice to the user and send back a 429 when you've received too many web requests. So much nicer than a hang up.

[spirilis 1,265]

The client.write() stuff probably isn't changing, but someone looking for hardcore performance could probably extend the API after sufficient studying of the lwIP internals.

 

Sent from my Galaxy Note II with Tapatalk 4