W5300 High-capacity data communication

Hello. TCP server mode, RX_FIFO size2k。 200 Mbytes of data are received from the PC, but “TCP ZeroWindow” occurs when receiving about 100 Mbytes, error stops with “RST”. What kind of things can be considered? Please give me advice

Share wireshark log. “TCP zero window” will happen after receiving first 2k if you do not flush data from RX buffers.

1 Like

Thank you for the e-mail.
We incorporate W5300 in the receiver of the printer.
Below is the contents checked here.
Reading from R_FIFO is executed by DMA.
//SOCK_ESTABLISHED: Receive
if((len=getSn_RX_RSR(s)) > 0) // check the size of received data
{
// Test200M data
len = recv(s,ep3_rxdat,len); // Datalength Read
//DMA Dest set
HeadAdr = (unsigned long)&FIFOW_0;
//DMA
dma_EthFIFOtoEgnFIFO_eth(len/2);

    //Read Only  DumyData Send
    if(getSn_RX_RSR(s) == 0)                     // check if the window size is full or not
    { /* Sn_RX_RSR can be compared with another value instead of ??0??,
      			according to the host performance of receiving data */
         setSn_TX_WRSR(s,1);                       // size : 1 byte dummy size
	 setSn_TX_FIFOR(s,0x00);  
   	 setSn_CR(s,Sn_CR_SEND);                   // send                         
      	 while(!(getSn_IR(s) & Sn_IR_SENDOK));     // wait SEND command completion 
      	 setSn_IR(s,Sn_IR_SENDOK);                 // clear Sn_IR_SENDOK bit       
   			}		                                                                         
    }
}
    break;

*Wireshark Error
PC:192.168.0.10 W5300:192.1680.3
Overall data amount PC spool: 200 Mbytes
Error occurrence: Approximately 100 Mbytes
PC⇒zerowindowprob W5300:no replay
PC⇒RST
Why does W5300 not respond?


Thank you in advance.

The cause of the problem is not W5300, it is your PC. You continuously send one byte to PC from W5300, and PC does not read it from its RX queue. Screenshot shows that PC has window size 4, then 3, then 2, then 1, and finally 0, and next write from W5300 to PC goes nowhere, so PC resets the connection shortly as communication looks broken.

Thank you for the e-mail.
I will change the conditions such as PC and check it.
I will report the results.

Hello.
I investigated PC window size.
os: window 7 98 M / 200 Mbytes received.
Initial value: 64200
Dummy data (ACK) from W 5300 1 byte Receive every -1

os: window 10 180 M / 200 Mbytes received.
Initial value: 64200
Dummy data (ACK) from W 5300 1 byte Receive every -1
It returns to the initial value on the way and then -1 after receiving the data.

I decided it was not a problem of W5300 but a problem of PC side.

I was rude in an unclear English sentence. (I am Japanese.)

Please also take a consultation.

Dear Great Contributor.
I can’t change TCPiPapps in my PC
To fix PC Window size, I tried to 0bytes ack data from w5300.

setSn_TX_WRSR(s,0); // size :0 byte dummy size
setSn_TX_FIFO(s,0x0000)

Wiresharklog
175kbytes/200Mbytes
192.168.0.3(w5300) ZeroWindow

What is the purpose of dummy size transfer?
What is the difference between dummy size 0 and dummy size 1?
Why does zerowindow occur in dummy size 0 ?

Best regards

You can see in wireshark packet #43 that it reports W5300 window size as 0. The situation simply means that W5300 stopped getting data from its RX buffers. Check your program driving W5300.

What is this “dummy size”? Using TCP you do should not send anything if it is not required by protocol. Does your protocol require sending these bytes?

Because now it is W5300 which stops clearing its RX buffer.

Dear Great Contributor.

What is this “dummy size”? Using TCP you do should not send anything if it is >not required by protocol. Does your protocol require sending these bytes?

The following is the TX transfer size.
setSn_TX_WRSR(s,0); // size :0 byte dummy size
setSn_TX_WRSR(s,1); // size :1 byte dummy size

Best regards

Dear Eugeny

Attached log is basic, flow and please tell me at the timing of a reply of ACK of W5300.

  • No.7,9,24 send the window-update packet when the window size is full
    *Please tell me at the timing of a reply of No.11,13,15,17,19,21.

Best regards

Not sure what you want to know about this picture. It just shows that IP address 10 connects to IP address 3, sends some data and then closes connection, and IP address 3 confirms the end of session. There seem to be no issue in the communication. The only strange thing is IP address 3 having PSH flag set in its ACK packets.

Dear Eugeny

IP address

Dear Eugeny

IP address10:PC
IP address3:W5300

No.6 192.168.0.10 192.168.0.3 TCP 2974 [ACK] Seq=1 Ack=1 Win=64240 Len=2920
No.7 192.168.0.3 192.168.0.10 TCP 60 [PSH,ACK] Seq=2921 Ack=1 Win=10238 Len=1

Under the condition of (Sn_Rx_RSR==0) we can understand that IP address3 sends [PSH,ACK] to IP address10.

The question is the condition of W5300 transferring [PSH,ACK] from IP address3 to IP address10 in the transfer below.
No.10 192.168.0.10 192.168.0.3 TCP 10274 [ACK] Seq=8761 Ack=3 Win=64238 Len=10220
No.11 192.168.0.3 192.168.0.10 TCP 60 [PSH,ACK] Seq=3 Ack=18981 Win=10238 Len=0

Best regards

Where did you see this condition from this Wireshark log?

What is your problem with this TCP/IP session? What are you trying to find in it?

For me another strange thing in the output is that W5300 is explicitly saying that it wants MSS=1460, but another device sends packets of 10KB in size.

You must:

  1. explain why this log is important for you and what you want to see in it;
  2. attach this log, bit only picture of it.

Dear Eugeny

Where did you see this condition from this Wireshark log?
It corresponds to the length of DumyData of Window size update in the reading process
of the data receive buffer of W5300.

setSn_TX_WRSR(s,1); // size :1 byte dummy size
setSn_TX_FIFO(s,0x0000)

1.explain why this log is important for you and what you want to see in it;
I use it with read only.
I am investigating ways to not subtract Window Size of IP address10.
I want to know how flow control is done.

Best regards

Dear Eugeny

  • \file socket.c
  • Implemetation of WIZnet SOCKET API fucntions

uint32 recv(SOCKET s, uint8 * buf, uint32 len)
{

setSn_CR(s,Sn_CR_RECV); // recv
/*

  • \warning send a packet for updating window size. This code block must be only used when W5300 do only receiving data.
    */
    // ------------------------
    // WARNING CODE BLOCK START

// M_04072008 : Replace Sn_CR_SEND_KEP with Sn_CR_SEND.
①//if(getSn_RX_RSR(s) == 0) // send the window-update packet when the window size is full
//{
// uint8 keep_time = 0;
// if((keep_time=getSn_KPALVTR(s)) != 0x00) setSn_KPALVTR(s,0x00); // disables the auto-keep-alive-process
// setSn_CR(s,Sn_CR_SEND_KEEP); // send a keep-alive packet by command
// setSn_KPALVTR(s,keep_time); // restore the previous keep-alive-timer value
//}

②// if(getSn_RX_RSR(s) == 0) // check if the window size is full or not
// { /* Sn_RX_RSR can be compared with another value instead of ==0,
// according to the host performance of receiving data */
// setSn_TX_WRSR(s,1); // size : 1 byte dummy size
// IINCHIP_WRITE(Sn_TX_FIFOR(s),0x0000); // write dummy data into tx memory
// setSn_CR(s,Sn_CR_SEND); // send
// while(!(getSn_IR(s) & Sn_IR_SENDOK)); // wait SEND command completion
// setSn_IR(s,Sn_IR_SENDOK); // clear Sn_IR_SENDOK bit
// }
//}

● Please tell me the difference between ① and ② in processing after receiving w5300 data. ● When ① is executed, normal transfer can not be performed. What do you think? ● How can I determine the comment of ②, the setting value of "another value instead of ==0" ?

Best regards

Dear tnk.

① doesn’t recommend because W5300 maybe operated in abnomal when the peer can’t send a ack packet of new DATA.

We recommend only ②. If it possible, it is good to use dummy data that does not affect the server .

"How can I determine the comment of ②, the setting value of “another value instead of ==0” ? "
the value 0 means my windows is full. The purpose of this code is to notify the peer if my window size has changed.
If you want higer performance, You can send a dummpy data when my window size is half, 1/3, 1/4 or any value.

thank you.

Dear midnigtcow
I use it with ReceiveOnly.
Transfer 1 Gbytes of data from the PC as one document.
ZeroWindow Error on the PC side is occurring.
When it is W5300 ReadOnly Mode, it is necessary to send 1 bytedummy, so in PC it is necessary to read 1 bytedummy?

thank you.

Dear tnk.

Yes, To avoid zero window on p-side, You should read a dummy byte.
This problem is W5300’s defection. So, For only receiving application, It is nessary to send a dummy data and read it on partner-side.

Thank you.

Dear midnigtcow
In the case of ReceiveOnly, it does not conform to protocol standards such as OSI.

thank you.