No Packet Loss Showing in Customized Ping

Dear Hossein,

If the Multi-Ping sensor requests fail in general, it will be counted as downtime. If one of the pings fails, it will be counted as Packet Loss. So if 4 of 5 requests succeed, the sensor will show 20% packet loss.

Also note that these low intervals, like 4 seconds, are not officially supported by PRTG, so I recommend to configure 10 s or better 30 seconds for the interval.

Kind regards,
Felix Saure, Tech Support Team

Thanks dear Felix
You tell about ping sensor in multi requests method.
I want to know about "one single ping" method.
What about this one? How do the "downtime" and "packet loss" work in this method?
Please consider the time interval again as 4 seconds.
Thanks a lot.

Dear Hossein,

I cannot encourage you to go on a 4 second interval, PRTG wasn't designed for that. If you use single Pings, every dropped packet is considered as downtime for the sensor.

Kind regards,
Felix Saure, Tech Support Team

I realized that, and i would not use intervals below 10 seconds as you said.
But I want to know: So the "packet loss" in the settings I've done has never happened and will never appear?
Settings:
Time out: 2s
Packet Size: 100 Bytes
Ping Method: 1 Single Ping Request
Interval: 4s
And I also want to know that the problem has nothing to do with timeout?
Thanks again

Dear Hossein,

You can check the log tab of the sensor to see if a Ping from PRTG towards this device failed. If not, it won't count in the packet loss.

The timeout defines when the ICMP messages is considered as dropped.

Kind regards,
Felix Saure, Tech Support Team

And one other question:
As you mentioned: "If you use single Pings, every dropped packet is considered as downtime for the sensor",
so why is there "packet loss" channel in single ping method sensors?

And: Can i set the "timeout" value higher than "interval" value for a ping sensor?
In this case, it seems to overlap with the next ping request.

Dear Hossein,

The packet loss channel is just considered if you configure more than one ping per interval. Ans choosing a timeout larger than the scanning interval will not work since it will overlap in PRTG's scheduler.

Kind regards,
Felix Saure, Tech Support Team

Dear Felix
Kindly Thanks for you patient and attention
Based on all of the above, what do you suggest for the closest implementation of the following request:
Monitoring a device through 1000 100-bytes ping requests within 1 hour.
Thanks again

Dear Hossein,

If you really want to pick this load on the target device, you could use the Multi-Ping sensor in a 30 second interval and send 5-8 pings with one scanning interval. This would result in 600 to 960 pings in total for an hour.

Kind regards,
Felix Saure, Tech Support Team

Kindly thanks for all of your tips in this ticket
I would like to offer a suggestion for better use of this sensor
The "ping delay" value should be between 5 to 100 ms
And this limitation makes it impossible to have the same time interval between pings in the multi ping method.
This means that in this method, depending on the maximum value of "ping delay" set, all ping requests are always send only at the beginning of the sensor interval, and then the tool waits until the next interval begins.
If we assume these settings:
Method: Multi Ping Request
Ping Count: 5
Ping Delay: 5ms
Interval: 60s
This will result in:
5 ping requests in 25 ms in beginning of the interval, wait 1 minutes, and repeat....
While it could be like below if we have 12s "ping delay" instead of 5ms:
1 ping request, wait 12s, another one, wait 12s, and go on, until the end of interval..
Best regards

Dear Hossein,

I see your point. Still I do not see the necessity to put a higher load on that host, which you simply want to check for the availability. If you start multiple pings from different sources, especially with a higher payload than the default ICMP packets, it somehow forces the target host to fail because of the monitoring, which is not reasonable to me.

Again thanks for your input.

Kind regards,
Felix Saure, Tech Support Team