WIZnet Developer Forum

W5500 is running ok,but link PC directly the ping timeout is big (20 ms) and the throughout is just 1Mbps

hi,
now we meet an error of network latency/delay by W5500 of spi(50MHz) qcom 8974 AP running Android OS with the direct link to PC, it’s about 20ms and the throughout is low (about 1Mbps)by testing of iperf tool(cmd such as iperf -c 192.168.1.1 -i 10 -t 30).couldyou please help us to check it.
tkx.
Youngtao

I recommend you installing Wireshark on the PC to obtain communication log with the device. There could be multiple causes for the issue, like

  • physical issue like broken cable (causing retransmissions)
  • your W5500 driver being a bottleneck and too slow in working with TX/RX buffers and control registers
  • if you use TCP take a look at Sn_MR register bit 5 “No delayed ACK” ensuring it is set when socket is initialized

thank you so much, Eugeny,
we will have a try, and give you our reply.
BR.
youngtao

I recommend you installing Wireshark on the PC to obtain communication log with the device. There could be multiple causes for the issue, like

  • physical issue like broken cable (causing retransmissions)
  • your W5500 driver being a bottleneck and too slow in working with TX/RX buffers and control registers
  • if you use TCP take a look at Sn_MR register bit 5 “No delayed ACK” ensuring it is set when socket is initialized[/quote]

hi,Eugeny,
today we find that there are no retransmission packets in all which are caught by wireshark tool.
and then we open the register function of no delayed ACK, but it doesn’t work to the timeout and throughout.
so you told us maybe its the linux w5500 driver bug, now we are checking the driver code, and could you please help us to review our w5500 driver code which is just uploaded? tkx a lot.

BR.
Youngtao
w5500.zip (737 KB)

Before anything I would like to see wireshark packet trace log to see the timing. Please attach it. Thank you.

hi,Eugeny,
the packets of ping and iperf are attached, and the device IP is 192.168.1.2, the PC IP is 192.168.1.100, please check them. thx so much.
BR.
youngtao
pcap.zip (117 KB)

Looking to the ping log I see that W5500 responds within 5-6ms for small packet size and large packet size, for packet size about 1K it responds within a 18 ms (e.g. 1280).
From test log I see that you allocated whole space of 16K for one socket. Packet size is 1214, and only two packets are being acknowledged in series (thus most of the allocated 16K buffer is not used). PC acknowledge comes almost immediately, and I see pattern in W5500 operation delaying its packets by ~8ms every time.

Here’re things you may need to focus on:

  1. You may not need 16K for the socket. I do not know how packet of 1214 bytes appears, it may happen that your testing tool loads data of this size and issues W5500’s SEND command. This is NOT optimized for performance. If you have 16K socket, you can put all 16K data in, and then issue SEND command and then W5500 will select maximal possible packet size for transmission. Remember that smaller packets will take longer time to transmit. Thus you either increase size of data, or decrease buffer size to 2K or 4K. I recommend to go to default 2K size as a test because 2K socket is default for W5500, I do not know how chip will behave for changed buffer size in terms of its socket performance.
  2. I still have a suspicion that you need to check setting of no delayed ACK bit. Before sending data in your test (after you opened socket and connection got established), read socket’s mode register and test for bit 5 to ensure it it set to 1 (in general, MR should be 0x21).
  3. W5100’s datasheet is having very good explanation of the programming of the socket in chapter 5. Please review it to ensure you perform sockets programming properly.

[quote=“Eugeny”]Looking to the ping log I see that W5500 responds within 5-6ms for small packet size and large packet size, for packet size about 1K it responds within a 18 ms (e.g. 1280).
From test log I see that you allocated whole space of 16K for one socket. Packet size is 1214, and only two packets are being acknowledged in series (thus most of the allocated 16K buffer is not used). PC acknowledge comes almost immediately, and I see pattern in W5500 operation delaying its packets by ~8ms every time.

Here’re things you may need to focus on:

  1. You may not need 16K for the socket. I do not know how packet of 1214 bytes appears, it may happen that your testing tool loads data of this size and issues W5500’s SEND command. This is NOT optimized for performance. If you have 16K socket, you can put all 16K data in, and then issue SEND command and then W5500 will select maximal possible packet size for transmission. Remember that smaller packets will take longer time to transmit. Thus you either increase size of data, or decrease buffer size to 2K or 4K. I recommend to go to default 2K size as a test because 2K socket is default for W5500, I do not know how chip will behave for changed buffer size in terms of its socket performance.
  2. I still have a suspicion that you need to check setting of no delayed ACK bit. Before sending data in your test (after you opened socket and connection got established), read socket’s mode register and test for bit 5 to ensure it it set to 1 (in general, MR should be 0x21).
  3. W5100’s datasheet is having very good explanation of the programming of the socket in chapter 5. Please review it to ensure you perform sockets programming properly.[/quote]

ok,Eugeny,thx a lot,
16k buffer code is from Chinese fae, so we keep it not changed, and now we wanna use the 8socket function for big bandwidth, do you have w5500 linux driver reference code of the 8socket register, because Chinese fae can’t supply it to us.
for we are now 1Mbps by 1 socket, maybe use 8 socket it will be about 8Mbps, or 5Mbps is ok.

If product you design is for commercial use, then wrong decisions on architecture may cause product sales issues.
Do you have TOR (terms of reference) defining who your customer is, and what functionalities this customer may want, and what exactly technical characteristics you should achieve?
Seems you do not want to take ownership or control over the architecture, relying on someone’s work - it is easy, but will not help success of your product. Point your Chinese FAE to this thread so that s/he reconsides the architecture of the solution.

This is very questionable assumption. 8 sockets will require more CPU load, and management of the data split between sockets, plus none will guarantee how W5500 will behave in response to your code design.

As I said - increase data load size to the buffer, this is first thing to try.

Ask WIZnet, check their software/driver download site. Most porbably you will find some libraries, but you should know that if you need performance (per TOR) standard solution may not be the best to use.

If product you design is for commercial use, then wrong decisions on architecture may cause product sales issues.
Do you have TOR (terms of reference) defining who your customer is, and what functionalities this customer may want, and what exactly technical characteristics you should achieve?
Seems you do not want to take ownership or control over the architecture, relying on someone’s work - it is easy, but will not help success of your product. Point your Chinese FAE to this thread so that s/he reconsides the architecture of the solution.

This is very questionable assumption. 8 sockets will require more CPU load, and management of the data split between sockets, plus none will guarantee how W5500 will behave in response to your code design.

As I said - increase data load size to the buffer, this is first thing to try.

Ask WIZnet, check their software/driver download site. Most porbably you will find some libraries, but you should know that if you need performance (per TOR) standard solution may not be the best to use.[/quote]

hi,Eugeny,
the buffer changing doesn’t work for the bandwidth, maybe the point of the bug is the working socket register NO. and by the way, our device memory is big enough for W5500, for the wifi bandwidth is 18Mbps or more in 5GHz channe. thx a lot, we will work out this bug according to you valuable suggestion.

BR.
YOUNGTAO

Youngtao, while I was focusing on the data throughput, I forgot issue related to ping having about 18 ms response. Ping performance has nothing to do with host driver/data performance, thus there really seems to be a problem.

I have W5100 custom board, just have run test to ensure that it replies within less than 1 ms to the nearby PC’s ping response. TX/RX buffer size does not affect ping response performance (as far as I see in my test). Thus I decided to take a look onto your driver code, finding out that you use WIZnet standard driver. I also see the following line in dev.c

however bit 2 is indicated to be reserved in the datasheet, searching for it gave me the following source github.com/borg42/w5x00/blob/master/dev.c saying the following

1483 // TMODE_NOSIZECHK_RAW (0x04) is defined as "reserved" in w5500 as well as w5x00 datasheet! wtf? 1484 iinchip_outb(lp->regs.REG_TMODE, TMODE_PINGBLOCK /*| TMODE_NOSIZECHK_RAW*/);
I would also disable this TMODE_NOSIZECHK_RAW bit setting in your driver (we can see it as being the undocumented functionality).

Further, I ask you please perform dump or whole “common register block” (0x0-0x39) after W5500 initialization is finished by the driver (e.g. before the driver goes to establishing/listening mode) - so that we can see which settings all the registers have and try to figure out potential issues.

[quote=“Eugeny”]Youngtao, while I was focusing on the data throughput, I forgot issue related to ping having about 18 ms response. Ping performance has nothing to do with host driver/data performance, thus there really seems to be a problem.

I have W5100 custom board, just have run test to ensure that it replies within less than 1 ms to the nearby PC’s ping response. TX/RX buffer size does not affect ping response performance (as far as I see in my test). Thus I decided to take a look onto your driver code, finding out that you use WIZnet standard driver. I also see the following line in dev.c

however bit 2 is indicated to be reserved in the datasheet, searching for it gave me the following source github.com/borg42/w5x00/blob/master/dev.c saying the following

1483 // TMODE_NOSIZECHK_RAW (0x04) is defined as "reserved" in w5500 as well as w5x00 datasheet! wtf? 1484 iinchip_outb(lp->regs.REG_TMODE, TMODE_PINGBLOCK /*| TMODE_NOSIZECHK_RAW*/);
I would also disable this TMODE_NOSIZECHK_RAW bit setting in your driver (we can see it as being the undocumented functionality).

Further, I ask you please perform dump or whole “common register block” (0x0-0x39) after W5500 initialization is finished by the driver (e.g. before the driver goes to establishing/listening mode) - so that we can see which settings all the registers have and try to figure out potential issues.[/quote]

tkx so much, Eugeny, i will catch the reg ASAP.

[quote=“Eugeny”]Youngtao, while I was focusing on the data throughput, I forgot issue related to ping having about 18 ms response. Ping performance has nothing to do with host driver/data performance, thus there really seems to be a problem.

I have W5100 custom board, just have run test to ensure that it replies within less than 1 ms to the nearby PC’s ping response. TX/RX buffer size does not affect ping response performance (as far as I see in my test). Thus I decided to take a look onto your driver code, finding out that you use WIZnet standard driver. I also see the following line in dev.c

iinchip_outb(REG_TMODE, TMODE_PINGBLOCK | TMODE_NOSIZECHK_RAW);

however bit 2 is indicated to be reserved in the datasheet, searching for it gave me the following source github.com/borg42/w5x00/blob/master/dev.c saying the following

1483 // TMODE_NOSIZECHK_RAW (0x04) is defined as "reserved" in w5500 as well as w5x00 datasheet! wtf? 1484 iinchip_outb(lp->regs.REG_TMODE, TMODE_PINGBLOCK /*| TMODE_NOSIZECHK_RAW*/);
I would also disable this TMODE_NOSIZECHK_RAW bit setting in your driver (we can see it as being the undocumented functionality).

Further, I ask you please perform dump or whole “common register block” (0x0-0x39) after W5500 initialization is finished by the driver (e.g. before the driver goes to establishing/listening mode) - so that we can see which settings all the registers have and try to figure out potential issues.[/quote]

hi,Eugeny,
the all log of device is attached, which include the all common REG value at the last several line just like this:
<6>[ 131.559261] *************SOCKET NO.:0, COMMON REG (0x000000) VAULE:0x14
sucomreg.zip (23.9 KB)

Youngtao, so what we have here…

MR (0) = 0x14. As I said in previous post try with bit 2 reset (so that it is 0x10).
GAR (1-4) = 0,0,0,0. W5500 uses gateway address to direct specific requests, for example it may perform some ARP queries to gateway. If there’s a gateway, set its address so that W5500’s requests to it would be properly fulfilled.
SUBR (5-8) = 0,0,0,0. This setting is ok if there’s no router (in your config GAR=0), thus I think GAR and SUBR all zeros, from standard point of view, should be ok, but it is a good question how these values are handled by W5500 internally. I never tried this way, I always had gateway and subnet mask (but I always use internet which requires router, in your case you just connect two devices without “outer world”, right?). Nevertheless, if there’s gateway in your setup, set subnet mask appropriately (as well as GAR).
SHAR (9-e) = 0,8,dc,91,97,98, looks like valid MAC address with no special bits set.
SIRP (f-12) = 0,0,0,0. From now on I think that you took the dump of the W5500 when it is not configured yet.
We need dump of fully configured W5500 when it is expected to answer ping requests.

Quickly on other regs:
SIMR (18) = 0x1, interrupts from socket 0 are enabled
RTR and RCR are default (7d0 and 8 respectively)
PHY (2e) = 0xba, configured by pins, all capable, current connection is 100MBit, and link is down! So, in addition to incomplete configuration, chip is disconnected from the LAN.

I also see the following:

where status of 0x42 is

So you are going to communicate using RAW mode, not TCP and not UDP-with-header modes, right?

Also looking at your log output

I would say you may confuse socket registers and common registers. Common registers set operating mode of the chip, socket registers set operating mode of the socket. Then I suspect that this is why you initialize socket 0 in MACRAW mode writing the same value 0x14 to S0_MR as well as to MR.

Please check carefully and reply with your findings.

[quote=“Eugeny”]Youngtao, so what we have here…

MR (0) = 0x14. As I said in previous post try with bit 2 reset (so that it is 0x10).
GAR (1-4) = 0,0,0,0. W5500 uses gateway address to direct specific requests, for example it may perform some ARP queries to gateway. If there’s a gateway, set its address so that W5500’s requests to it would be properly fulfilled.
SUBR (5-8) = 0,0,0,0. This setting is ok if there’s no router (in your config GAR=0), thus I think GAR and SUBR all zeros, from standard point of view, should be ok, but it is a good question how these values are handled by W5500 internally. I never tried this way, I always had gateway and subnet mask (but I always use internet which requires router, in your case you just connect two devices without “outer world”, right?). Nevertheless, if there’s gateway in your setup, set subnet mask appropriately (as well as GAR).
SHAR (9-e) = 0,8,dc,91,97,98, looks like valid MAC address with no special bits set.
SIRP (f-12) = 0,0,0,0. From now on I think that you took the dump of the W5500 when it is not configured yet.
We need dump of fully configured W5500 when it is expected to answer ping requests.

Quickly on other regs:
SIMR (18) = 0x1, interrupts from socket 0 are enabled
RTR and RCR are default (7d0 and 8 respectively)
PHY (2e) = 0xba, configured by pins, all capable, current connection is 100MBit, and link is down! So, in addition to incomplete configuration, chip is disconnected from the LAN.

I also see the following:

<6>[  131.566781] sock:0 SOCK_STATUS = 0x42 , Protocol = 0x14

where status of 0x42 is

0x42 / SOCK_MACRAW / This indicates Socket 0 is opened in MACRAW mode (S0_MR(P[3:0]) = ‘0100’)and is valid only in Socket 0. It changes to SOCK_MACRAW when S0_MR(P[3:0] = ‘0100’ and OPEN command is ordered.

So you are going to communicate using RAW mode, not TCP and not UDP-with-header modes, right?

Also looking at your log output

<6>[  131.559261] *************SOCKET NO.:0, COMMON REG (0x000000) VAULE:0x14

I would say you may confuse socket registers and common registers. Common registers set operating mode of the chip, socket registers set operating mode of the socket. Then I suspect that this is why you initialize socket 0 in MACRAW mode writing the same value 0x14 to S0_MR as well as to MR.

Please check carefully and reply with your findings.[/quote]

hi,Eugeny,

we set and dump the common reg again by PC linked directly, and now it doesn’t work to the timeout, in our opinion, there must be something block the ping echo reply packet, maybe it’s some function such as iinchip_mac_rx_tasklet() .

and from the “ping block” (0x10)description of DS, it means there is no reply to ping request ? could we disable it by setting 0bit?

the 5500 chip have a function of auto reply ping, could we open it to check the 5500 is running ok in our device especially the chip pin is ok.

by the way the new common register list is attached, please check it. tkx.
BR.
YOUNGTAO
reglog.zip (687 Bytes)

From my perspective log looks fine now.
And you have checked it still has 20 ms delay in reply to ping request?

I still see

You still initialize socket in RAW mode. Please open socket 0 in TCP mode setting S0_MR into 0x21, and then giving command 0x01 (open) to CR, and only then try pinging W5500.

If ping still gives long time values, I would change course of action - would designed “dummy” driver for W5500, which would only contain the following:

  1. software reset (MR bit 7 set to 0, then waiting till this bit resets);
  2. set MR to 0x10;
  3. set proper GW IP, mask, MAC address, and own IP address;
    and that’s all - not changing anything else from the defaults. Then I would try to ping W5500 and see result. If it would have the same 20 ms reply, the issue might be not in the chip OR you may have found issue in the chip. If ping will be ok (1ms), then there’s some issue in your further chip configuration (e.g. it does not handle single 16KB buffer properly) - and it will require further troubleshooting.

[quote=“Eugeny”]From my perspective log looks fine now.
And you have checked it still has 20 ms delay in reply to ping request?

I still see

<6>[   83.356338] sock:0 SOCK_STATUS = 0x42 , Protocol = 0x14

You still initialize socket in RAW mode. Please open socket 0 in TCP mode setting S0_MR into 0x21, and then giving command 0x01 (open) to CR, and only then try pinging W5500.

If ping still gives long time values, I would change course of action - would designed “dummy” driver for W5500, which would only contain the following:

  1. software reset (MR bit 7 set to 0, then waiting till this bit resets);
  2. set MR to 0x10;
  3. set proper GW IP, mask, MAC address, and own IP address;
    and that’s all - not changing anything else from the defaults. Then I would try to ping W5500 and see result. If it would have the same 20 ms reply, the issue might be not in the chip OR you may have found issue in the chip. If ping will be ok (1ms), then there’s some issue in your further chip configuration (e.g. it does not handle single 16KB buffer properly) - and it will require further troubleshooting.[/quote]

hi,Eugeny,

we set the socket 0 MR to 0x21 and CR to 0x01, then the network is fail, and the ping is fail too, because that the mac address will not be learned each other, if we use cmd"arp -s x x" to bind the ip and mac by manual, it still doesn’t work.that is why set the raw protocol, and now the common register and protocol status is as following:
protocol status.zip (709 Bytes)

hi,Eugeny,
the photo is the test result and the tcpdump packet.
BR.
YOUNGTAO


Youngtao, I am very sorry, I was mistaken about MR value. Datasheet says

To be ping-able device should have bit 4 as ZERO, not 1. Thus please, after you software reset the chip with bit 7 (MR <- 0x80), just wait until this bit clears, and no further operation on MR is necessary. When you will have bit 4 of common register “MR” to 0, W5500 will be replying to ping requests.

You actually were already saying that in

but I did not read it well.

Next,

you have opened socket (status 0x13) in TCP mode and with no delayed ACK bit set. Good!

So now your task is to connect to the PC using CONNECT command (CR <- 0x04), and if connect is successful, status reg will become 0x17. Then you can send and receive data.

For successful connect PC should listen to the respective destination port in TCP mode. DP (destination port #) should be set in W5500’s socket registers 0x10-0x11.

During connection command execution, you should see packet exchange between W5500 and PC - probably several ARP packets, and TCP SYN/ACK packets.

But before proceeding to TCP connect, please check timing of ping to see if it is still 20 ms, or timing has improved.

hello Eugeny,
i am sorry to disturb you .BUT i have met a problem and hope your help.
linux 3.18 with w5500 driver , read and write regs are ok .

Under macraw model ,but i cannot ping my w5500 wit pc
HOpe you help .Thx

Copyright © 2017 WIZnet Co., Ltd. All Rights Reserved.