---
title: "W5100, Delayed ACK despite bit ND/MC being set"
url: "https://maker.wiznet.io/forum/15252"
markdown_url: "https://maker.wiznet.io/forum/15252/md"
type: "Forum topic"
category: "Ethernet Chips"
author: "Jean-Michael Staab"
created: "2024-08-01T09:37:32+09:00"
last_activity: "2024-08-07T08:22:41+09:00"
language: "en"
views: 20
replies: 4
source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)"
---

# W5100, Delayed ACK despite bit ND/MC being set

## Question

Asked by Jean-Michael Staab on 2024-08-01 in Ethernet Chips.

Hello everyone,
Despite the ND/MC bit being set in the socket mode register, the W5100 sends the ACK with a delay of 200 ms for small received telegrams (16 bytes). I cannot get the W5100 out of this habit.
Background: W5100 is the client and has connected to an SCPI server (measuring devices). If I now request measured values (READ?), the measured value telegram arrives after approx. 3.9 ms. However, the W5100 only sends the ACK for this telegram after 200 ms. This behaviour is independent of whether the delayed ack is switched on or off via the ND/MC bit.

Can someone please help me?

## Replies

### Reply 1 by Eugeny, 2024-08-01

Telegram is something related to the post office business.

Ensure you are in TCP mode.
Prove that this bit is really set for this MR by reading it back when problem occurs.

Next, at which point you measure the time? You must measure at the W5100’s jack (on the direct connect node). All other measurements may include other network devices which may add delays to the packets.

### Reply 2 by Jean-Michael Staab, 2024-08-06 (in reply to reply 1)

Thanks for the quick reply.
Yes, I am in TCP mode.
I write S2_MR = 0x21 for TCP and NDACK. When I read back, it correctly reads 0x21. The W5100 stubbornly sends its ACK exactly after 200 ms. This means that it also takes 200 ms until I have received the measured value. That is far too long. Especially as the measured value was already sent after 3 ms and has been in the W5100’s buffer for a long time. However, the W5100 only reports receipt when it has sent the ACK after 200 ms. I will post a WireShark protocol here. Measurements are made directly at the W5100 connector using a hub, not a switch. This means that the PC, the measuring device and my controller, which is to read out the measuring device, are connected to this hub.

### Reply 3 by Eugeny, 2024-08-06

I recall having problem with long ACK times long ago, but thein it was resolved, but I do not recall what it was. What I remember for sure it was not a rocket science or something unimaginable ![:slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12)
Here’s more info - [delayed ACK](https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment).
It says that the mechanism is two-way street - sending side is also involved and must obey the specific RFC not withholding with data for single packet.
Your investigation using Wireshark must give an idea what is going on the network in reality and who is the source of delay.

### Reply 4 by Jean-Michael Staab, 2024-08-07

Hello Eugeny,

thank you very much for your support. NDACK is working. The error was 60 cm in front of the monitor. If you only call the handle for reading the data from the W5100 every 200 ms, you should not expect [ACK] to be sent faster. My mistake.
Thanks for your help though. I was able to rule out that it was the W5100.

---

Source: https://maker.wiznet.io/forum/15252