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

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

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

cheers

cabs

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

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?

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 :)

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

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

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?

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

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

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 packets@172 bytes@every 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

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

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 :)

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

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.

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

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

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

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.

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

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.

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

Thanks

cabs

Hi Cabs, just send the whole Logfile.

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

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.

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.

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

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.