Re: [lwip-users] Re transmission problem?

[Jordan Dean]

 I am using RAW.  I didn't mess with any timer stuff, what I did do is
define NO_SYS_NO_TIMERS=1 in opt.h and that seemed to take care of any of
the weirdness with the new timer stuff.  I still just call the tcp timers as
I did with the old stuff and it's working great (20-30% throughput increase
running tcp).

-Jordan

-----Original Message-----


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.htm
>> l 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 mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users