New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

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

 

Top Tags


View all Tags


QoS (Quality of Service) Round Trip Sensor-values?

Votes:

0

Your Vote:

Up

Down

So I'm using the above on multiple Pi's, and it seems pretty good.However, on one or two, the channels go high sometimes (MoS, jitter etc). I think I know what the problem is (too many packets hitting the device the Pi is behind is being seen as some sort of DDOS issue) .I say this as lowering the packet rate from the default of 1000 to 100 cures the issue, so its not a PRTG problem as such. But I would like to know where the defaults come from-1000 packets every 20ms at 172 bytes each seems a bit excessive? And this repeated every 60 seconds-have I got this right? If this is to test the likes of a VoiP circuit, is that the sort of packet rate (the byte size sounds about right) you would have?

Thanks

qos qos-reflector voip voip-sensor

Created on Jul 23, 2015 5:37:17 PM by  cabsandy (0) 1



28 Replies

Votes:

0

Your Vote:

Up

Down

It's probably a bit excessive for the Raspberry - are you using the 1 or 2?

Created on Jul 24, 2015 11:20:46 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi there Raspberry Pi 1 B+ I am conscious though of mimicking VoiP traffic though

cheers

cabs

Created on Jul 24, 2015 1:23:43 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Hm you could use the QoS reflector python script by Konstantin as an endpoint for the roundtrip sensor and see how that works out :)

Created on Jul 27, 2015 7:04:26 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

That one needs the Pi to be a Miniprobe-I like the way the current one works from you guys. Its just a questions around how you got to your values?

20ms is a good interval for VoiP packets-I'm using 232 bytes, rather than the 172, as 232 fits mimicking our systems better (DOCSIS). My main query is where you came up with 1000 packets. At one every 20ms, thats a continous stream at the Pi for 20 seconds ?? (1000 x 20ms=20 seconds). Seems a lot for ANY endpoint? And then repeat 60 seconds later?

Created on Jul 27, 2015 8:55:19 AM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Sorry for the late publishing! My colleague who develops the mini probe is currently out of the office and will join us again tomorrow. He'll answer your question then :)

Created on Jul 29, 2015 10:49:51 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi,
the default 1000 packets have been a developer decision when the sensor first was introduced. Since then it has not been changed, so you might consider this as a historical grown setting. I opened up a ticket to change the defaults down to 500 packets but cannot guarantee if or when this will be implemented.
Best regards

Created on Jul 30, 2015 1:58:55 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Thanks again for the reply-one last thing. We were testing this last night, and noticed, using wireshark, that the PRTG server, when set to 20ms, was actually sending out the packets at 30/31ms interval. We then changed it to 15ms, and it sent out at 15ms (as described). Changed the interval to 16,17 and 19ms and it was still sending out packets at a rate of 30ms. The machine is an i5 Windows 7. Can you confirm with your test machines that when set at 20ms, the server actually does pump out packets at 20ms? This is to test a Voip circuit and it is critical we can mimic the actual voice call by sending packets to the Pi at a rate of 20ms.

I can send you a pcap trace if you want, with the delta times between each 172 byte packet at 30ms if required

thanks

cabs

Created on Jul 31, 2015 7:02:46 AM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Hm, I can't reproduce it - there's indeed a slight abberance, but it was only ±1ms in my capture. Are you using the latest version of PRTG?

Created on Aug 3, 2015 9:22:13 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Sorry for the lateness in replying but I have been working on this for a few days.It is really weird-when I run Wireshark on the PRTG server, the time is exactly (give or take a ms) 10 ms MORE than the configured Time between Packets-so if 20ms, WS shows 30ms.If its 50ms, WS shows 60ms-its like there is something being added on, somewhere. I have another PRTG server, and that happily does 20ms in WS when pointing at the same QoS reflector device (Pi Ver B+). Using other sensors in the suspect PRTG, they all come back with this +10ms when looking at WS traces. The WIN7 machines are of the exact same spec, and I have double checked the settings in the network adaptors-they are both the same.

I dont think this is a PTRG problem, as the other machine is fine, but any pointers for the suspect one would be gladly received.I have a .pcap file if you want to see it

Thanks

cabs

Created on Aug 6, 2015 9:26:35 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Sorry, no idea. Maybe another user has a tip? :)

Created on Aug 10, 2015 7:40:39 AM by  Stephan Linke [Paessler Support]

Last change on Aug 10, 2015 7:41:10 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Ok I'd like to resurrect this-I done the following upgrade this morning

NewToDo ticket: Software update This is a recommended update for all users. You are using version 15.1.15.2021, the new version is 15.3.18.3591. Most recent message of the Auto Update System: [18/08/2015 15:41:29] Version 15.3.18.3591 has been downloaded and is ready for installation. Please visit Setup|Autoupdate to initiate the installation.

Before the upgrade, sniffing on my remote probe showed 20ms, bang on time.As soon as the upgrade was finished ,and the Core and Probe services restarted, the time went up to 30ms (so the PRTG server is set to 100 [email protected] [email protected] 20ms). Playing with the interval, if I move down to 15 ms, the probe showed 15ms inbound.If I them move anywhere above 15ms (to 16,17,18,19,20ms etc), the probe shows 30ms.The only thing that has changed is the server version.I have rebooted the client probe and the server, but no joy.Is there way to downgrade, or any ideas on this? 20ms is crucial to what we are looking to do, as its the standard size for VoiP transmission

thanks

cabs

Created on Aug 21, 2015 2:34:09 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Another thing to add to my last post-I have set up the same probe on a prtg box running 15.2.17.2803 and the remote QoS probe shows 20ms when using t-shark for packet sniffing. So there is definitely something up with your latest round of updates, when it comes to the Time between Packets (ms) setting?

cheers

cabs

Created on Aug 21, 2015 3:01:37 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

We'll have to wait for the sensor developer here I'm afraid - this will take a while, since he's currently on vacation until the end of the month :)

Created on Aug 25, 2015 7:55:49 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi there Thanks for the reply-as it worked ok in 15.1.15.2021, and then "broke" in 15.3.18.3591, is there a way I can download the previous version, uninstall/clean the "new" version, and try again? It is a very small install, only 2 devices and four sensors, so not difficult to rebuild

thanks

cabs

Created on Aug 25, 2015 9:52:19 AM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

I assume it's a freeware version? Can you check your C:\Program Files (x86)\PRTG Network Monitor\download directory? It should contain the installer. Note that you may need to restore your configuration from a backup that was made before the update. They reside in C:\ProgramData\Paessler\PRTG Network Monitor\Configuration Auto-Backups.

Created on Aug 25, 2015 10:37:06 AM by  Stephan Linke [Paessler Support]

Last change on Aug 25, 2015 12:04:30 PM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Sorry-only just seen this reply.Unfortunately, when I look in the folder, I dont see the previous versions. The only version I have is a 14.4, and when I try to install that, it says the installer is out of date, and points me to the latest one. Have you a link to the 15.1.15.2021 and have you asked the developer what the problem is?

Thanks

Created on Sep 15, 2015 9:27:11 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Sorry, we don't store old installers/versions that long :( How about the prtg-installer-for-distribution folder?

Created on Sep 16, 2015 8:43:16 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Ok We are willing to purchase a copy if this gets increased focus-here is where we are:

1) rolled back to 15.2.17.2803+ 2) deleted all configuration files and rebooted server 3) put in probes IP's again

When we do a tshark packet trace on the probe (Pi), if you put the sensor at 15ms, you see inbound UDP packets every 15ms-so thats fine. As soon as you go to 16ms, the inbound and outbound UDP packets jump to 30ms?? Surely this isn't right, and should be easy for you guys to confirm or deny?

Cheers

cabs

Created on Sep 16, 2015 12:14:18 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Hi cabs, the code in Question is basically:

for iii := 0 to packetcount -1

{

SetPacketValues(Buffer);

UDP.SendBuffer(Buffer);

CurrentThread.Sleep(PacketInterval);

}

So the realtime packetinterval tolerance mainly depends on the CPU/OS Sheduler. There is a chance that the 16ms border causes the Thread to be passivated by the OS Sheduler and therefore the ScanningThread needs more time to actually return from the sleep. There was no Change in the specific Code Area between the Versions in Question.

Created on Sep 23, 2015 2:49:46 PM by  Mathias Hengl [Paessler Support]

Last change on Sep 23, 2015 2:50:06 PM by  Mathias Hengl [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi The code you refer to is in PRTG-yes? Its not something in the Pi/Linux/QOS reflector script-I am unclear as to where this code is.

If so, nothing else has changed in the setup I use, apart from upgrading PRTG (which is when the problem started).20ms being a default for most Voice applications, i am unclear how this QOS script can be used by most operators-do you see the same problem in your test setups?

Thanks

cabs

Created on Sep 23, 2015 3:47:02 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Hi cabs, yes its PRTG side code. As i cannot reproduce your Issue please open up a Support Tcket and send us Logs from your Core and Probes.

Created on Sep 25, 2015 8:09:10 AM by  Mathias Hengl [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Mathias Many thanks-I will get this done-any specifc logs or timeframes?

Thanks

cabs

Created on Sep 25, 2015 4:51:03 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Hi Cabs, just send the whole Logfile.

Created on Sep 29, 2015 12:58:07 PM by  Mathias Hengl [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi So the logfile is sent, and hopefully the guys are looking at it, but if you see this post, something else to be aware of. Running PRTG on multiple machines, with the latest version installed-I am still getting the 30ms spacing, with 20ms configured on the probe. But if you look at the below, I can bring it back "into line" to 20ms by starting a download to a random website (say speedtest.net). Once the download is finished, it goes back to 30ms. Its as if there is some internal buffering going on at the PRTG side,when it "sees" other traffic? I can replicate this behavior on ANY machine, which runs the latest version. Also, sniffing on the PRTG server with Wireshark shows 30ms spacing being sent out by the PRTG server, with 20ms set up. Very strange!

0.019907 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.020146 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.020148 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.026744 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.012996 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.022232 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.023810 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.016028 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.018302 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.019719 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 0.022082 serverip>>>remote probeip UDP 214 Source port: 61674 Destination port: 11002 19.545530 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002 0.029646 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002 0.039668 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002 0.022101 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002 0.033171 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002 0.029059 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002 0.031878 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002 0.031877 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002 0.032061 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002 0.029992 serverip>>>remote probeip UDP 214 Source port: 61712 Destination port: 11002

Created on Oct 26, 2015 3:16:09 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Dear cabsandy

Mathias will have a look at this, but he is not available for the next weeks. Please wait until he returns to the office.

Created on Oct 28, 2015 1:19:32 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Dear cabsandy

Our developer responsible for this sensor had another look. PRTG does not appear to modify the time differences.

We also got no further notices of a similar behavior from other users; making us believe that PRTG in fact works as intended.

Created on Dec 3, 2015 2:05:09 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Thanks for the reply Not sure where I go with this then as it worked for 20ms-and now it doesn't. I can replicate the fault at will, on different machines, with multiple Pi's. We will need to go to another solution for our VOIP customers-all 4 million of them

Thanks

cabs

Created on Dec 3, 2015 3:14:32 PM by  cabsandy (0) 1



Votes:

0

Your Vote:

Up

Down

Hi Cabs, as Arne mentioned i had another look and test session about your problem.

The only code change that could maybe affect your situation was an adjustment of the scanning thread Priorities under certain circumstances. You can try to elevate the probe process priority by 1 level. Besides that, as i mentioned before, PRTG uses a plain "CurrentThread.Sleep(PacketInterval);".

PRTG does not run on a real time plattform and therefore some tolerances has to be taken into account.

Created on Dec 7, 2015 8:22:38 AM by  Mathias Hengl [Paessler Support]



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.