[Top][All Lists]

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

Re: [lwip-users] Delays over WiFi

From: Sergio R. Caprile
Subject: Re: [lwip-users] Delays over WiFi
Date: Wed, 18 May 2016 10:42:03 -0300
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.1.0

Sorry for the delay, I overlooked this thread.
Perhaps your application is not filling the TCP buffer ? I can't help with the socket API, but I see the following:
        the client issues a POST request
        the server responds and announces the content length
        200ms later, the client ACKs
        the server then sends the announced content.
the server could have sent the data without waiting for an ACK, providing it had enough room, and the application is well written to take advantage of it (I can't help you here, I'm RAW API only)

But this is not the culprit.
In the POST starting at #10304, I see the client ACKs as usual, but this frame seems to get lost somewhere. I bet you captured at the client, so we can't know if the server got it. We don't know even if the AP sent it... you should get an AirPcap or similar to pinpoint on this. One second later, the keepalive triggers and the server sees an ACK number it likes, so it sends the response data, the content. This could be minimized if you trim your app, but you need to check whether your frames are being lost at the AP, at the Redpine, or at the STM driver.

You will eventually lose frames on a WiFi network, so if you can't tolerate these delays, you need to setup shorter timeouts. Your application is very sensitive to timeouts because you are not taking advantage of the frame length and buffering capacity (providing you have it... I bet you do, what is your MTU ? your TCP_MSS and TCP_SND_BUF ? --> lwipopts.h)

reply via email to

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