W5500 EVB Loopback UDP test

Question

Hi, I’m getting 4 milli roundtrip (measured with Wireshark) while running the UDP loopback test. I’m a bit dissapointed. Expected sub-milli performance. Am I doing something wrong? Are you guys or gals getting better results?

arthurbe · Answer

I’m evaluating W5500 EVB board for delay performance only. Throughput is not interesting in my case, actually small UDP datagrams sent from PC (1 byte in payload) and looped back from W5500 + LPC11E36 on W5500_EVB. I measure the delay between send and receive on PC with Wireshark and get 4 millisecond. The PC runs a dot.net UDP client program to send and receive the datagrams. Same test performed with two PCs one with the same client dot.net program and the other runs dot.net echo UDP server. Same measurement with Wireshark I get 2.5 milliseconds roundtrip. It is impressive to get such results on a small ARM with the help of W5500 but I’m looking for a sub-millisecond roundtrip in my application. I guess it is possible with W5500 but the “socket API” software that runs on the ARM it is what slows things down. Is there a method to close the loop at the W5500 itself without copying to the micro each received datagram? Do you think the W7500 should have better performance in the same setup?

arthurbe · Answer

Did you try the ping? Thanks Eugeny, You right the ping (ICMP) is done solely at the W5500. To be sure I hold the LPC11E36 in reset still getting the ping response, got 2 ms for ping roundtrip. I tryied with a different network driver on PC and got 500microseconds!! On the same PC network driver the previous UDP echo test goes down to 2.5 milli. (instead 4ms) Can we asume small UDP fragment and ICMP takes approx. the same time on W5500? and the additional 2millisecs is all in the micro? What can I do to squiz it further?

arthurbe · Answer

Eugeny: What is the difference in drivers and their settings? What is the difference you see in the Wireshark? Now you see that network performance is very dependent on the software, while hardware of course plays significant role here. the slower is a USB to ETHERNET Lenovo adaptor I use on my laptop for another i/f. Eugeny: Usually it is the case 2 ms to recvfrom/sendto ?? I wrote an SPI master on ssp1 to read from Altera MAX10 FPGA: static void max10_read(uint8_t addr, uint8_t* rbuf) { Chip_GPIO_SetPinState(LPC_GPIO, 1, 23, false); Chip_SSP_WriteFrames_Blocking(LPC_SSP1, &addr, 1); Chip_SSP_ReadFrames_Blocking(LPC_SSP1, rbuf, 2); Chip_GPIO_SetPinState(LPC_GPIO, 1, 23, true); } this function takes 35 micro! (measured on osciloscope). Where all 2ms goes in recvfrom\sendto?

Eugeny · Answer

arthurbe: 2 ms to recvfrom/sendto ?? Usually it is the case what design and architecture of the software is a bottleneck. Hardware is usually predictable in its performance. arthurbe: the slower is a USB to ETHERNET Lenovo adaptor I use on my laptop for another i/f. I think it should be logical that intermediary adds the delay. arthurbe: Where all 2ms goes in recvfrom\sendto? This is good question, I do not know unless you explain what you do exactly. But I am sure as you will deep dive in how it works you will find the possible location and causes of delay yourself.