Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Client Loss Rate AMD to Server or Client to AMD?

Dynatrace Pro
Dynatrace Pro

Hi all,

DC RUM 12.4.10

While investigating an issue at a customer, we have seen the metric Client Loss Rate (AMD to Server) being at around 8%. However, we expected to see the Client to AMD part to be at that value.

A bit more context, we are analyzing traffic between RF devices in a warehouse and a load balancer in a remote DC. The AMD is next to the LB with a latency < 1ms and we dont expect to see any loss on that side. On the client site side, we do expect some packet loss as per the physical layer and the ongoing issue. ICMP statistics show we do lose packets on that side.

Are we misunderstanding the definition of Client loss rate (AMD to server) or is it possible the value is sent to the wrong metric?

Thank you,



DynaMight Leader
DynaMight Leader

Hello Nic,

Client Loss Rate to Server is the percentage of total packets sent by a client that were lost between the server and the AMD and needed to be re-transmitted.

Server Loss Rate to Client is the percentage of total packets sent by a server that were lost between the AMD and the client and needed to be re-transmitted.



Of course, it is supposed to be that.

Dynatrace Pro
Dynatrace Pro


Basing on your system description, I assume RF devices initiate TCP connection to the LB. If so, then the situation you describe indicates that some packets sent by RF devices have been seen by the AMD, but are not acknowledged by the LB. This is possible if the LB weren't doing a good job and this won't be visible to ICMP pings because ICMP packets are not processed by the TCP part of the node stack (LB in this case).

So it looks that the proof can only be obtained with smart packet capture and analysis of such capture in DNA or Wireshark. BTW, recently we've been running a test in the lab for one of our SEs to showcase how to use the four loss rate metric on two AMDs to point exactly at a culprit on a noisy WAN link, so I guess the metrics accuracy has been confirmed by the way of this exercise.

If the initial assumption is not true and connection establishment goes the other way around (which can be imagined with some extra gateways in the middle), then the situation would indeed indicate packet loss on the RF network side (because RF side would be the server).

Best regards

Thank you Kris, I'll investigate that with the customer.