UDP Loopback Timing

I initialized Wiznet w5100 and then I created UDP socket of 2kb buffer size. I connected Linux System with W5100. The loop back time I saw in Linux system is 3.5 milli seconds, which is more than the excepted time.
The MCU that connected with wiznet is operating at 48 MHz with 12 MHz SPI Speed. The following is the time excepted to loop back data of size 1 byte:

Total read using interrupt: 57 micro seconds
Total write : 42 micro seconds

Total time : 99 micro seconds

I have also integrated the Wiznet API driver, but the loop back time is still around 3.7 milli seconds. Please help me resolve this ASAP.

Thanks in advance,
Conan.

Resolve what? You want some application of your linux host to show 99 microseconds?
Your post misses a lot of information, and it is not clear how did you get 99 us.

And your post sounds like statement of work rather than problem desciprion (“I want byte to return in 99 us”), and performance tuning requires deep knowledge about networking and platforms/software you use.

Hi Eugeny,
Thanks for the quick response!

The Linux system is having a UDP Client code. I calculated the time before sending and after receiving the data. For Linux to Linux it shows a total time of 0.5 milliseconds, but using the Wiznet W5100 IC, it takes around 3 milliseconds (instead of the expected 99microseconds). This 99 microseconds is the total expected time for writing and reading SPI registers based on calculations. The Wiznet IC is connected directly to the system (No Ethernet Hub is used).

I want to know the response time of the Wiznet w5100 after receiving data from client using RECV interrupt and send response time after send command (The communication response time of the IC), as I cant find any availiable information regarding this; and also how I can optimize it, if optimization is possible.

I bet you will not; this info seems to be proprietary and can be ontained only through experience and from this page listing max speeds.

Possible, but for this full unsderstanding of what’s going is needed. And also because of precise understanding how chip works internally there could be cases when optimizations applied will not be effective (e.g. errors and jams on highly loaded networks).

W5x00 works as intermediary and queue for network access, thus total throughput and speed will depend on how quick (and properly) chip is being driven, and what is going on the network. Look into all parts is necessary to find the bottlenecks out.

While MCU may be clocked quickly, it is algorithm which matters - see the datasheet, it has good explanation on how to handle the UDP operation. Also look at the Wireshark output (installed on Linux) to find out patterns and possible issues in timing. Finally perform send-only from W5100 in loop and measure time between arriving UDP packets.

@wizteam Can you provide any information/suggestions on the matter as well?

Dear Conan!

W5100’s internal send processing time(ISPt) is the sum of SEND command process time(St), Packet Generanting Time (Pt) and SENDOK time(SOt).
ISPt = St + Pt + SOt
= [4 X NIC_CLK] + [2 X NIC_CLK x{SMAC(6) + DMAC(6)+EtherType(24)+IPHeader(20)+UDPHeader(8)+DataSize(N)+CRC(4)}] + [6 X NIC_CLK]

ex> N = 1 when 100BaseTx
ISPt = (4+ (49X2) + 6) X 40ns = 3520ns = 3.52us
ex> N= 1 when 10BaseT
ISPt = (4+ (49X2) + 6) X 400ns = 35200ns = 35.2us

W5100’s Interanl receive processing time(IRPt) is sum of Packet Parsing Time(PPt) , Data Saving Memory(DSt) + Destination Saving Time(DSt) and RECV Interrupt time(RIt).
IRPt = PPt + DSt + RIt
= [ 2 X NIC_CLK X { Presemble(8) + SMAC(6) + DMAC(6) + EtherType(2) + IPHeader(20) + UDPHeader(8) + CRC(4)}] + [Data(N) X 2 X NIC_CLK] + [ 24 X NIC_CLK] + [ 26 X NIC_CLK]

ex> N = 1, 100 baseTx
IRPt = (2 X( 54 + 1) + 50) X 40 = 160 X 40ns = 6400ns = 6.4us
ex> N = 1, 10 baseTx
IRPt = (2 X( 54 + 1) + 50) X 40 = 160 X 400ns = 64000ns = 64us

So, All Round trip time is sum of Host Data copy time to Socket TX memory(TXt) , ISPt, Netwrok Jiitter(NJt), IRPt, and Recv Data Copy time(RXt)

Here, TXt, RXt, NJt depends on Host performance and Network situation.
These time is hart to predict.

It seems to take a long time because the SPI access interval per byte is too large.

You need optimize the code for reducing SPI access interval per byte.

1 Like