[lwip-users] lwip 1.3.2 waiting for ACK problem

[Peter Pavlov]

Hi,

I need some help.
During developing lwip based firmware (without RTOS) I met problem with
big image slow downloading speed. This problem is not new one, I saw many
topics related to this issue, but all mentioned solutions seem not working
on 1.3.2 version. So question is how to send more segments packets without
waiting for ack. I have tried many ways to solve this problem but still no
success. Changing memory settings allows to send bigger packets but this
helps a little.

Thanks for any help,
Peter Pavlov

Wireshark log:

16230 20802.761850 192.168.0.31 192.168.0.32 TCP
54 53584 > http [ACK] Seq=356 Ack=103522 Win=65392 Len=0
16231 20802.771584 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16232 20802.771586 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16233 20802.971032 192.168.0.31 192.168.0.32 TCP
54 53584 > http [ACK] Seq=356 Ack=104546 Win=65392 Len=0
16234 20802.979820 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16235 20802.979822 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16236 20803.171028 192.168.0.31 192.168.0.32 TCP
54 53584 > http [ACK] Seq=356 Ack=105570 Win=65392 Len=0
16237 20803.179816 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16238 20803.179818 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16239 20803.261506 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16240 20803.261508 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16241 20803.261743 192.168.0.31 192.168.0.32 TCP
54 53584 > http [ACK] Seq=356 Ack=107618 Win=65392 Len=0
16242 20803.271586 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16243 20803.271588 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16244 20803.471049 192.168.0.31 192.168.0.32 TCP
54 53584 > http [ACK] Seq=356 Ack=108642 Win=65392 Len=0
16245 20803.479822 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16246 20803.479824 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16247 20803.680030 192.168.0.31 192.168.0.32 TCP
54 53584 > http [ACK] Seq=356 Ack=109666 Win=65392 Len=0
16248 20803.688831 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16249 20803.688833 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16250 20803.761501 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]
16251 20803.761505 192.168.0.32 192.168.0.31 TCP
566 [TCP segment of a reassembled PDU]

_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[Simon Goldschmidt]

"Peter Pavlov" <peter_...@mail.ru> wrote:
> Wireshark log:

Please provide wireshark logs as pcap file, not as text dumps. Also, please describe what you think is wrong in a capture (referencing packets by their number in the pcap log). Additionally, please always provide information on what you recorded (e.g. which application, if it's helpful) and describe which IP address is lwIP and what type of hardware the other end is (e.g. which OS, etc.).

In your case, please also attach your lwipopts.h file (since you said changing it made a difference).

Thanks,
Simon
--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

[Peter Pavlov]

I recorded communication between Firefox and controller with embedded http
server (based on lwip).
Controller IP 192.168.0.32
PC IP 192.168.0.31
Log 1.pcap shows part of communication when picture was loading in
Firefox. As you can see lwip sends 2 or 4 packets with image segments fast
and then waits for ack. Why only 2 or 4 can be sent? According my
investigation problem relates to tcp_output(struct tcp_pcb *pcb) in
tcp_out.c It would be great to play with number of segments to send
before moment when ack is required.

Peter Pavlov

[Simon Goldschmidt]

"Peter Pavlov" <peter_...@mail.ru> wrote:
> I recorded communication between Firefox and controller with embedded http
> server (based on lwip).

Is that the httpserver_raw from contrib?

> Controller IP 192.168.0.32
> PC IP 192.168.0.31
> Log 1.pcap shows part of communication when picture was loading in
> Firefox.

Ideally, please include the start of a TCP stream in a pcap: wireshark sometimes provides better parsing when the SYN packets are included.

> As you can see lwip sends 2 or 4 packets with image segments fast
> and then waits for ack. Why only 2 or 4 can be sent? According my
> investigation problem relates to tcp_output(struct tcp_pcb *pcb) in
> tcp_out.c It would be great to play with number of segments to send
> before moment when ack is required.

The longer delays (~200 ms, e.g. between packets 4 & 5 or 7 & 8) suggest you have a memory allocation problem, which could either be running out of heap memory or one of the limitations (TCP_SND_BUF or TCP_SND_QUEUELEN) holds tcp_write() back from enqueueing more data.

The other delays (~80ms, e.g. between packets 10 & 11 or 21 & 22) are strange though: your target simply delays sending but that cannot be related to resource restriction as no ACK comes in between (unless you have other communication running in parallel which might free resources in between?).

I'd suggest turning on debugging to see if tcp_write() returns an error and/or have a look at lwip_stats to see if you get memory allocation errors.