W5500 EVB Loopback UDP test

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?

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?

Did you try the ping?

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
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?

In my opinion ping - if it is being answered by the W5500 chip in automatic mode (PB bit in MR register is 0) should be the fastest packet round trip time. If ping request is being answered by the software (W5500 driver in MC) then round trip time would heavily depend on the performance of the driver.

Usually it is the case.

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.

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?

Usually it is the case what design and architecture of the software is a bottleneck. Hardware is usually predictable in its performance.

I think it should be logical that intermediary adds the delay.

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.