What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

QoS sensors

Votes:

0

Your Vote:

Up

Down

We have turned on the QoS sensors and we see random times where there is packet loss but we cannot seem confirm what the QoS sensor is showing. We have logged into the routers switches and firewalls and cannot see any packet loss. It is possible the QoS sensor is giving false readings?

prtg qos sensor

Created on Mar 15, 2010 6:33:49 PM by  Mark (0) 1

Last change on Mar 16, 2010 8:38:10 AM by  Daniel Zobel [Product Manager]



Best Answer

Accepted Answer

Votes:

0

Your Vote:

Up

Down

The faulty values for "Packet Loss" were due to a bug in the "Garbage Collection" mechanism which regularly removes expired packets. We have fixed this. The fix will be reflected in the next update release of PRTG.

Created on Jan 7, 2011 2:52:35 PM by  Patrick Hutter [Paessler Support] (7,225) 3 3



12 Replies

Votes:

0

Your Vote:

Up

Down

Between what nodes did you setup the QoS sensor?

Are the two probes in your local LAN?

Created on Mar 15, 2010 8:38:03 PM by  Aurelio Lombardi [Paessler Support]

Last change on Mar 16, 2010 8:38:21 AM by  Daniel Zobel [Product Manager]



Votes:

0

Your Vote:

Up

Down

The QOS sensors are on a local probe and remote probes that are on lans that are inside our network. They are not going over the internet but are going between various internal networks. I even set up 2 probes on the same subnet and I also get random periods of packet loss between 2 probes on the same subnet. I am assuming I should see no packet loss or at least not very often.

Created on Mar 16, 2010 4:47:25 PM by  Mark (0) 1



Votes:

0

Your Vote:

Up

Down

what is the scanning interval? If it is 1min please increase to e.g.5 min

Maybe add a ping sensor between the probes as well with a ping count of e.g. 50 and check if you see any packet loss for the ping sensor

Created on Mar 18, 2010 9:15:49 AM by  Aurelio Lombardi [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I've just started myself with a QoS sensor and notice the same. With a default setup QoS Sensor I notice even 5 min intervals (on the 2 days Tab) in which 50% Packets Lost appears! This is between two sites connected through a MPLS connection of 20 Mbit.

Anyone else who has the same issues?

Created on Apr 7, 2010 9:30:20 PM by  Patrick Mast (90) 1 1



Votes:

0

Your Vote:

Up

Down

Is this for the hole day (constantly) or for certain times.

Did you already add a PING sensor with a ping count >1

Created on Apr 8, 2010 11:17:03 AM by  Aurelio Lombardi [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I'm also seeing reports of 50% packet loss by the QOS sensor every 14-15 minutes on the nose (all the other values were 0%). The machines for server core and remote probe were connected to the same switch so there is nothing in the way between them.

Just to be sure, I ran smokeping against the remote probe machine for 45 minutes (100 pings per minute) and saw zero packet loss.

I believe that this is a bug with the QOS sensor.

Created on Jan 4, 2011 8:44:12 PM by  jared (0) 1



Votes:

0

Your Vote:

Up

Down

I just started today with PRTG and QoS sensor and encountered the same problem i.e. random packet loss indication. I've also added a Ping sensor (count 50) and it does not indicate packet loss. Sensors are set to update every 60sec. What would cause the packet loss indication? This over an MPLS WAN. I find it hard to believe that we have real packet loss.

Created on Jan 6, 2011 8:20:04 PM by  svemuri (0)



Votes:

0

Your Vote:

Up

Down

@svemuri: Please keep in mind that PINGs are using ICMP while the QoS sensor uses UDP, so both measurements can be completely different.

@jared, @svemuri: We will look into the potential problem!

Created on Jan 7, 2011 8:31:14 AM by  Dirk Paessler [Founder Paessler AG] (10,984) 3 5



Votes:

0

Your Vote:

Up

Down

Thanks for looking into it. I understand that Ping is ICMP. However, in our network, it has the lowest priority (QoS settings). UDP (between certain IP ranges) has highest priority (VOIP). So, If anything we should see packet loss on ICMP PING before we see it on UDP.

Created on Jan 7, 2011 1:41:16 PM by  svemuri (0)



Accepted Answer

Votes:

0

Your Vote:

Up

Down

The faulty values for "Packet Loss" were due to a bug in the "Garbage Collection" mechanism which regularly removes expired packets. We have fixed this. The fix will be reflected in the next update release of PRTG.

Created on Jan 7, 2011 2:52:35 PM by  Patrick Hutter [Paessler Support] (7,225) 3 3



Votes:

0

Your Vote:

Up

Down

In my case, there are regular short spurs of 50% packet loss every 14-15 minutes that last about 8 seconds. However, with my initial testing, the core server and the remote probe were on Windows 7 virtual machines so that *may* be a possible reason for this oddity.

During another test using a QOS sensor between two physical (Win7) machines, I verified that this setup didn't manifest the spurs of packet loss. Without further analysis, my educated guess right now is that it may be a problem with a network buffer inside VMware Workstation when using Windows 7 VMs. I know that Windows 7 VMs have only recently started to be officially supported inside VMware workstation so all may not be fully kosher yet.

If you are able to replicate this oddity with your developer team, you may want to talk with VMware engineers to get to the root of the problem.

Hope this helps!!

Created on Jan 7, 2011 2:53:19 PM by  jared (0) 1



Votes:

0

Your Vote:

Up

Down

I'm now seeing this issue between two physical machines on PRTG 8.1.2.1809. I'll be testing the 8.2.0.1897 release. It's apparently not VMware related and may be attributed to that bug that has been already identified above.

Created on Jan 21, 2011 5:32:44 PM by  jared (0) 1



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.