[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Re transmission problem?
From: |
Phil Perryman |
Subject: |
Re: [lwip-users] Re transmission problem? |
Date: |
Mon, 16 May 2011 08:53:25 -0700 (PDT) |
Jordan,
Thanks for the advice, I've upgraded from 1.3.0 to 1.3.2 and changed the
timer interrupt as per your recommendation and it no longer stops after
10mins. Porting to 1.4.0 doesn't seem quite as straightforward when using
the raw api (NO_SYS=1). I replaced the ethip_hdr in etharp.h however, the
new timers.c file uses a sys_now function for retrieving timestamps and
tells you to call sys_check_timeouts periodically from main.c, did you have
to do this or are you using socket api?
Thanks
Phil
Jordan Dean-2 wrote:
>
>
> Phil,
>
> That's correct, the only thing you have to do is replace the etharp struct
> (or something like that) that was removed in 1.4 with the pieces of it
> that
> matter (used for checksum offload), and there's an example in some of the
> lwip code of how to do that. If you search on the Xilinx website there's
> some instructions for calling the library out of
> /board_support_package/sw_services/<name of library> which is what we do,
> as opposed to modifying the code in the Xilinx directory. You also make a
> few changes in the makefile and in the Xilinx .tcl file if you need / want
> any of the new options. It only took me about a day to port (and about 2
> days to track down the timer issue).
>
> The timer issue seems like it wouldn't be a big deal but it is, and
> actually
> with 1.4 it will only run for ~30 seconds before getting the
> retransmission
> weirdness. With 1.3 we were able to run for ~12-24 hours before it
> happened.
>
> -Jordan
>
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Phil Perryman
> Sent: Friday, May 13, 2011 8:22 AM
> To: address@hidden
> Subject: Re: [lwip-users] Re transmission problem?
>
>
> Hi Jordan,
>
> Thanks for your reply, I will give this a try, though I'm surprised it
> runs
> for as long as it does if it's a timer issue, though I guess it would
> explain why a retransmission occurs for no apparant reason.
>
> When you say port the Xilinx driver to 1.4 do you mean use the drivers in
> the contrib folder with the latest version of lwip?
>
> Thanks for you help,
> Phil
>
>
> Jordan Dean-2 wrote:
>>
>> I have seen the exact thing using the Xilinx lwip examples. There are
>> a few things (I have since found out) that are wrong about the way
>> they have the examples set up. The first thing to do is to fix the
>> way they call the timers.
>>
>> Xilinx sets up the microblaze timer and uses the interrupt to call
>> tcp_fast and slow timers, this is incorrect. What you need to do to
>> fix the weird ack problems is to use the Xilinx timer interrupt to set
>> a global flag do_tcp_fast and do_tcp_slow. Check those global flags
>> in your main program loop and use them to call the timers (not from
>> the interrupt context).
>> This
>> fixed these types of issues for me.
>>
>>
>> Then what you need to do is port the Xilinx driver to 1.4, it works
>> much smoother.
>>
>> -Jordan
>>
>> Sent: Friday, May 13, 2011 3:56 AM
>> To: address@hidden
>> Subject: [lwip-users] Re transmission problem?
>>
>>
>> Hi,
>>
>> I am currently running LwIP 1.3.0 v3.01a on a Xilinx dev board
>> connected to a host PC and using the RAW API. To measure the maximum
>> bandwidth I repeatedly transmit blocks of 1400 bytes from the board to
>> the PC using the module at the end of this email called in a while
>> loop from main.c.
>>
>> I achieve a bandwidth of 100Mb/s however between 5-10mins transmission
>> stops. Looking at the Wireshark capture below there is a
>> retransmission at
>> 462735 of the previously sent frame (462733) followed by a duplicate
>> ACK, the next frame sent is the frame which would be expected if the
>> retransmission did not occur. From this point on there are several
>> duplicate ACKs but the frames between the ACKs are not retransmitted
>> frames.
>>
>> Does this indicate a problem with LwIP retransmission? As after the
>> retransmission I would have expected the next frame in the seqeuence
>> not the frame after that which the retransmission replaced.
>>
>> Also I have noticed that occasionally there are 3 frames between ACKs,
>> should it not always be 2 for every ACK at this data rate?
>>
>> Thanks for your help,
>> Phil
>>
>> Wireshark capture:
>>
>> 462720 41.694753 192.168.1.10 192.168.1.2 ECHO
>> 1454
>>
>> Response
>> 462721 41.694901 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462722 41.694914 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> 57774 > echo [ACK] Seq=4242681 Ack=430759001 Win=65535 Len=0
>> 462723 41.694953 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462724 41.695106 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462725 41.695121 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> 57774 > echo [ACK] Seq=4242681 Ack=430761801 Win=65535 Len=0
>> 462726 41.695155 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462727 41.695314 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462728 41.695334 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> 57774 > echo [ACK] Seq=4242681 Ack=430764601 Win=65535 Len=0
>> 462729 41.695370 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462730 41.695516 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462731 41.695531 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> 57774 > echo [ACK] Seq=4242681 Ack=430767401 Win=65535 Len=0
>> 462732 41.695571 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462733 41.695733 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462734 41.695750 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> 57774 > echo [ACK] Seq=4242681 Ack=430770201 Win=65535 Len=0
>> 462735 41.695789 192.168.1.10 192.168.1.2 ECHO
>> 1454 [TCP Retransmission] Response
>> 462736 41.695800 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> [TCP Dup ACK 462734#1] 57774 > echo [ACK] Seq=4242681 Ack=430770201
>> Win=65535 Len=0
>> 462737 41.695924 192.168.1.10 192.168.1.2 ECHO
>> 1454 [TCP Previous segment lost] Response
>> 462738 41.695940 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> [TCP Dup ACK 462734#2] 57774 > echo [ACK] Seq=4242681 Ack=430770201
>> Win=65535 Len=0
>> 462739 41.696079 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462740 41.696101 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> [TCP Dup ACK 462734#3] 57774 > echo [ACK] Seq=4242681 Ack=430770201
>> Win=65535 Len=0
>> 462741 41.696203 192.168.1.10 192.168.1.2 ECHO
>> 1454 Response
>> 462742 41.696219 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> [TCP Dup ACK 462734#4] 57774 > echo [ACK] Seq=4242681 Ack=430770201
>> Win=65535 Len=0
>> 462743 41.696253 192.168.1.10 192.168.1.2 ECHO
>> 1454 [TCP Out-Of-Order] Response
>> 462744 41.696261 192.168.1.2 192.168.1.10 TCP
>> 54
>>
>> [TCP Dup ACK 462734#5] 57774 > echo [ACK] Seq=4242681 Ack=430770201
>> Win=65535 Len=0
>> 462745 41.703125 192.168.1.2 192.168.1.10 ECHO
>> 1514 Request
>> 462746 41.703131 192.168.1.2 192.168.1.10 ECHO
>> 594
>>
>> Request
>> 462747 41.734051 192.168.1.2 192.168.1.10 ECHO
>> 1514 Request
>> 462748 41.734056 192.168.1.2 192.168.1.10 ECHO
>> 594
>>
>> Request
>> 462749 41.749768 192.168.1.2 192.168.1.10 ECHO
>> 1514 Request
>> 462750 41.749776 192.168.1.2 192.168.1.10 ECHO
>> 594
>>
>> Request
>> 462751 41.765325 192.168.1.2 192.168.1.10 ECHO
>> 1514 Request
>> 462752 41.765331 192.168.1.2 192.168.1.10 ECHO
>> 594
>>
>> Request
>> 462753 41.983547 192.168.1.2 192.168.1.10 ECHO
>> 1514 [TCP Retransmission] Request
>> 462754 42.591959 192.168.1.2 192.168.1.10 ECHO
>> 1514 [TCP Retransmission] Request
>> 462755 43.675781 192.168.1.10 192.168.1.2 TCP
>> 60
>>
>> echo > 57774 [ACK] Seq=430771601 Ack=4250681 Win=8192 Len=0
>> 462756 43.675840 192.168.1.2 192.168.1.10 ECHO
>> 1514 Request
>>
>> Transfer data module:
>>
>> int
>> transfer_echo_data()
>> {
>> err_t err;
>> struct tcp_pcb *tpcb = connected_pcb;
>>
>> if (!connected_pcb) {
>> xil_printf("Not connected\r\n");
>> return ERR_OK;
>> }
>>
>> if (tcp_sndbuf(tpcb) > SEND_BUFSIZE) {
>> err = tcp_write(tpcb, send_buf, SEND_BUFSIZE, 0);
>> if (err != ERR_OK) {
>> xil_printf("Error on tcp_write: %d\r\n", err);
>> connected_pcb = NULL;
>> return -1;
>> }
>> tcp_output(tpcb);
>> }
>>
>> send_buf[1]++;
>>
>> return 0;
>> }
>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Retransmission-problem--tp31609608p31609608.html
>> Sent from the lwip-users mailing list archive at Nabble.com.
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/Retransmission-problem--tp31609608p31611415.html
> Sent from the lwip-users mailing list archive at Nabble.com.
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
--
View this message in context:
http://old.nabble.com/Retransmission-problem--tp31609608p31630423.html
Sent from the lwip-users mailing list archive at Nabble.com.
- [lwip-users] Re transmission problem?, PhilJP, 2011/05/13
- Re: [lwip-users] Re transmission problem?, Kieran Mansley, 2011/05/13
- Re: [lwip-users] Re transmission problem?, Jordan Dean, 2011/05/13
- Re: [lwip-users] Re transmission problem?, Tyrel Newton, 2011/05/13
- Re: [lwip-users] Re transmission problem?, Phil Perryman, 2011/05/14
- Re: [lwip-users] Re transmission problem?, Jordan Dean, 2011/05/16
- Re: [lwip-users] Re transmission problem?,
Phil Perryman <=
- Re: [lwip-users] Re transmission problem?, Jordan Dean, 2011/05/17
- Re: [lwip-users] Re transmission problem?, Simon Goldschmidt, 2011/05/17
- Re: [lwip-users] Re transmission problem?, Jordan Dean, 2011/05/17
- Re: [lwip-users] Re transmission problem?, Tyrel Newton, 2011/05/17
- Re: [lwip-users] Re transmission problem?, Bill Auerbach, 2011/05/17
- Re: [lwip-users] Re transmission problem?, Phil Perryman, 2011/05/19
- Re: [lwip-users] Re transmission problem?, Simon Goldschmidt, 2011/05/19