Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

tse transmission get hanged in TCP protocal

Hello,everyone!

I want to transfer data between my laptop(the OS is windows XP) and my Stratix III 3sl150 board through ethernet wire. I'm using the hardware and software design found here: stratixiii_3sl150_dev_tse_sgmii_v1.zip (http://www.alteraforum.com/forum/attachment.php?attachmentid=1233&d=1246537769), the mode is "10/100/1000mac wtih 1000 base -x/sgmii"(1000Mbps & full Duplex mode). When using this design, the simple socket sever exmaple works well.

Afterward, I changed the software design to test the stability of the connection, in TCP protocal. I use my Stratix III board as server, and my laptop as client. And made a for loop in both end to send and receive data: stratix iii, receive 1, send 2; laptop, send 1, receive 2. So, if the connection is stable, the loop will never be stop. But practically, the loop get hanged after some time, and I don't know why.

Should it be a hardware problem(timing problem) or I do not write the software code right?

Can anyone help me please?

16 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I use high-definition video transmissions through UDP up to 400Mbps. Even a single packet is not lost on gigabit LAN...

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Use a tool such as Wireshark on the PC to see what is happening on the Ethernet link.

    One issue I had with TCP connections was that the Nios application couldn't handle the TCP window size it was advertising. The FIFO would get full too fast and some packets would be lost, triggering retransmissions. You see this very well in wireshark, when the connection gets really slow you see lots of red packets with "retransmission" written on them.

    If this is what is happening, then you have two solutions:[list][*]find a way to reduce the TCP window size (probably somewhere in the Interniche TCP/IP stack code)[*]increase the TSE Rx fifo size in SOPC builder/QSys to be at least as big as the TCP window size (32kbytes IIRC).[/list]
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Use a tool such as Wireshark on the PC to see what is happening on the Ethernet link.

    One issue I had with TCP connections was that the Nios application couldn't handle the TCP window size it was advertising. The FIFO would get full too fast and some packets would be lost, triggering retransmissions. You see this very well in wireshark, when the connection gets really slow you see lots of red packets with "retransmission" written on them.

    If this is what is happening, then you have two solutions:[list][*]find a way to reduce the TCP window size (probably somewhere in the Interniche TCP/IP stack code)[*]increase the TSE Rx fifo size in SOPC builder/QSys to be at least as big as the TCP window size (32kbytes IIRC).[/list]

    --- Quote End ---

    In wireshark, I got the red packets as follows:

    
    11	0.218182	169.254.228.129	169.254.228.120	TCP	 4858 > 30  Seq=1 Ack=33 Win=65503 Len=0
    13	1.814164	169.254.228.129	169.254.228.120	TCP	 4858 > 30  Seq=1 Ack=33 Win=65503 Len=2        there are a lot  in this kind
    

    I'm sorry, I'm new to wireshark, can you explain me what does these packets mean?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    yang,

    From your original post I see you are sending 2 byte buffers and wait for the answerback data before the next send. This is really inefficient because:

    - every packet needs to transfer 56bytes for a mere 2 byte data payload, because of Ethernet/IP/TCP protocol headers

    - the tcp protocol overhead will require a complete tcp/ip transaction (3 ethernet packets) for every cycle which only transfers 2 + 2 data bytes

    - you are using the socket connection in a synchronous way, waiting an answer for every request. The dead time between send and recv (due to Nios application, tse MAC and line delays) will prevent the system to achieve the maximum allowed speed

    Note that there's no problem with a 2bytes send itself, since the OS can pack bytes coming from multiple calls. The problem is the next receive which blocks until the answer bytes are received.

    You can try this modified code; it should be much more fast:

    while(1){

    cnt++;

    for (i=0; i<100; i++) {

    send(sockClient,"1",2,0);

    printf("1 sent OK!\n\n");

    }

    for (i=0; i<100; i++) {

    recv(sockClient,recvBuf,2,0);

    printf("%s\nrecieved OK!\ncnt=%d\n\n",recvBuf,cnt);

    }

    }
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    while(1){

    cnt++;

    for (i=0; i<100; i++) {

    send(sockClient,"1",2,0);

    printf("1 sent OK!\n\n");

    }

    for (i=0; i<100; i++) {

    recv(sockClient,recvBuf,2,0);

    printf("%s\nrecieved OK!\ncnt=%d\n\n",recvBuf,cnt);

    }

    }

    --- Quote End ---

    Thank you for your reply, Cris72

    I've tried your code, but it is of no use, the loop stopped when cnt =156. I think it is not a software code efficiency problem.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The dup ack and out of order packets seem to indicate that you are indeed loosing packets on the link.

    Do you see any packets with a "window resize" message? If yes try to increase the TSE rx fifo to 32kbytes in SOPC Builder/QSys.