W5200 different speed with different PC

Question

Hi, I’m using the WIZ820io module which contains the W5200 in TCP mode and I need to transmit at the maximum speed from the module to a PC. The connection is direct, no switch in between. With my custom hardware I’m clocking the SPI at 70MHz, and connecting it to some PCs I’m able to obtain a continuous throughput of 70Mb/s. I’m using two sockets with 8kB memory for TX and RX for both. So far so good. With other PCs instead the situation is different: I cannot go beyond 42Mb/s, and that is strange because they are very fast workstations with lot of RAM and multiple fast CPU. My custom hardware is behaving in the same way in both cases. I start saying that I disabled delayed ack in the PC, so that if possible it should ack each single packet received. From my hardware I issue send commands of full buffers (8192 bytes) each time (eventually dividing it in two if exceeding the maximum socket address). I analyzed with Wireshark why this happens and I discovered one curious thing. PC_1 trace: Pkt1 received: 1460 bytes. Pkt2 received: 1460 bytes. PC ACK for packets 1 & 2. Pkt3 received: 1460 bytes. Pkt4 received: 1460 bytes. PC ACK for packets 3 & 4. Pkt5 received: 1460 bytes. Pkt6 received: 892 bytes. PC ACK for packets 5 & 6. 700 us delay. Pkt1 received: 1460 bytes. Pkt2 received: 1460 bytes. PC ACK for packets 1 & 2. Pkt3 received: 1460 bytes. Pkt4 received: 1460 bytes. PC ACK for packets 3 & 4. Pkt5 received: 1460 bytes. Pkt6 received: 892 bytes. PC ACK for packets 5 & 6. 700 us delay. PC_2 trace: Pkt1 received: 1460 bytes. Pkt2 received: 1460 bytes. Pkt3 received: 1460 bytes. Pkt4 received: 1460 bytes. PC ACK for packets 1, 2, 3 & 4. 700 us delay. Pkt5 received: 1460 bytes. Pkt6 received: 892 bytes. PC ACK for packets 5 & 6. 700 us delay. Pkt1 received: 1460 bytes. Pkt2 received: 1460 bytes. Pkt3 received: 1460 bytes. Pkt4 received: 1460 bytes. PC ACK for packets 1, 2, 3 & 4. 700 us delay. Pkt5 received: 1460 bytes. Pkt6 received: 892 bytes. PC ACK for packets 5 & 6. 700 us delay. The W5200 divide each packet in MTU as expected and each packet is sent at maximum speed (about 70 Mb/s I think). But there are strange delays that make the overall throughput decrease for PC_2. For PC_2 the transfer speed is indeed 819228/(700us*4) = 46Mb/s. As you can see the only difference is that PC_1 is able to ack every two packets and that result in an high throughput. Instead PC_2 is maybe not fast enough to ack every two packets but ack after the first four. But it is indeed very fast too because (I didn’t indicate it) from Pkt4 to ack there are 10 us, so this delay isn’t the problem. The problem I think is in some way inside the W5200, because after receiving the ack of the fourth packet it takes additional 700us to send the other data (and I send to W5200 full 8192 packets, so the chip should have already all the data). I’m not able still to understand why and how to overcome this. What is the reason of this delay in your opinion? Do you think it is better…

Eugeny · Answer

Insufficient information. Please generate full Wireshark logs for both cases and upload them here.

mikkamano · Answer

Here they are, the ACK sequence I described is actually a little different but the strange delays are still there. I’ll wait some advice! Thank you in advance, Michele Wireshark trace from 2 PCs.zip (757 KB)

Eugeny · Answer

PC_1 acknowledgement of every single packet. PC_2 I see 700us delay. Set “enable no delayed ack” in W5200 (you said you did it in PC). Delay may be caused by your application delaying issuing SEND command to W5200 (e.g. tiem spent transferring data to W5200’s buffer), it is not necessarily the chip’s issue.

mikkamano · Answer

Dear Eugeny, Although that No delayed ACK option refers to the data transfer in the other direction (that is from PC to W5200), I already set that option. The acquisition you see are already taken with No delayed ack option enabled.

mikkamano · Answer

Moreover, I tell you another thing. My application currently writes in the TX buffer 512 Bytes each time. Then before issuing the send command it waits that the TX buffer (8kbytes) is full (so after 16x512 bytes write commands to the TX buffer). So the delay between two 8kB transfers could be due to my application or to the chip. But the delay of 700us inside the 8kB transfer I think is related to some chip issue, because the chip should already have at the beginning all the necessary data to complete the 8kB transfer! That’s is why I don’t understand this delay. Thank you in advance for further help.

mikkamano · Answer

Dear Wiznet support, I found a solution to the problem I reported which at the end resulted as an undocumented chip bug. I changed a bit my part but I repeat that the main problem is inside the W5200. I am able to push the W5200 to 70Mbit/s indepently from the PC. But I won’t report here the solution I found because of the weak support I received here. I bought a lot of chips and I and other customers often need a certain level of support to get the things work properly. This support given in this forum I think is poor, not only looking at my case but also looking at the lot of others unanswered topics. On my side this results in using the chips that I’ve left here and then searching other producers for future revisions. I think you, Wiznet guys, should spend more time here in order not to loose other customers. At least if you don’t know the causes of all problems be honest and say “it’s a bug/limitation of W5200 chip, solved in W5300, please upgrade to that model”. That would point out what what is really feasible with your products and what it’s not, and make your products more trustful. Anyway if some other user is interested at my case and want to know how I managed to push the W5200 TCP mode to the limit, send me an email and I would be glad to give you some other information.