The Ping test monitor is designed to assess the reachability and performance of a destination by sending ping packets from Catchpoint nodes. The destination can be specified using either an IP address or hostname. Each test run sends five packets of roughly 64 bytes each, capturing key metrics such as round-trip time (RTT) and packet loss.
Ping Test Use Cases
- Network Uptime Monitoring: Ensure continuous network availability by detecting and alerting on downtime instantly.
- Performance Benchmarking: Measure and compare network performance metrics such as round trip time and packet loss across different locations.
- Troubleshooting Network Issues: Quickly identify and diagnose network problems by pinpointing high latency or packet loss areas.
Ping-TCP and Ping-UDP are intended to calculate the round-trip time of the packets, but not port reachability. This means a Ping-TCP or Ping-UDP test may succeed even if the TCP or UDP port is down.
If you need to test for TCP/UDP port reachability, then you can use the Transport TCP or UDP monitors.
Ping Test Results
In this example, the Smartboard for a ping test reveals a noticeable spike in network metrics, specifically round-trip time and jitter. This sudden increase in jitter suggests network instability or congestion, which can adversely affect the performance of real-time applications.
Ping – Continuous
The ping test can be configured to perform checks continuously from any Enterprise Node (using points or flat rate.) This enables the detection of micro-outages lasting only a few seconds. Continuous Ping is configured by selecting a ping frequency of 200ms, 500ms, or 1000ms (1 second). Continuous ping probes will run in parallel with a 2000ms (2 seconds) timeout for each ping. For point-consumption calculation purposes, one minute of continuous ping testing at any of these frequencies is counted as a single test run.
Continuous frequency settings can be found under Targeting & Scheduling in the test properties blade.
Here, the Records page for a continuous Ping test highlights a brief spike in observed round trip time (RTT).
Ping Test Configuration
Below are the different test settings, advanced settings and metrics supported by Ping test.
Ping Test Properties | |
|---|---|
| Name | A name used to identify this test. |
| Description | Optional additional information about the test |
| Monitor | The protocol used for the Ping test.
|
| Test Location | The IP address or hostname of the host to be tested. (www.domain.com or 8.8.8.8. TCP/UDP can specify the port, e.g. www.domain.com:82) |
| Location | The Product/Folder location of this test (read only) |
| Status | Determines whether this test is current Active or Inactive |
Ping Test Advanced Settings | |
|---|---|
| Verify Test on Failure | Runs the test again from the same node in the event of failure. If a second test to verify a failure does run, then additional points will be consumed, which match the type of test and any other advanced settings that are enabled. The first failed test run will appear on the waterfall with an "This was the first test for the interval, which failed and was repeated.” However, it will not be included in performance charts, reports, or alerts. The second test run, that ran to verify the failure, will always be included in performance charts, reports, and alerts. |
| Debug Primary Host on Failure | Runs Ping, Traceroute, and DNS traversal to the primary host on test failure. |
| Enable MTU Path Discovery | Enables collection of Traceroute Path MTU data. Only works with Ping test if additional monitor is enabled to run traceroute. |
| Additional Monitor | Runs an additional Traceroute from the same node to the destination.The supported additional monitors are:
|
Supported Metrics | |
|---|---|
| # Purged Runs | The number of test runs manually excluded from calculation for purposes of SLA accuracy. |
| # Runs | Total number of test runs for the defined time period. |
| % Adjusted Availability | Ignoring any purged runs, the percentage of test runs where the primary URL server was reached and the test was completed (i.e. there was not a Test Error.) |
| % Availability | The percentage of test runs where the destination was reached and the test was completed (i.e. there was not a Test Error.) Availability is calculated as: (# Test Runs - # Test Errors) / # Test Runs |
| % Downtime | The percentage of test runs where the destination was unavailable, unreachable, or otherwise failed (i.e. there was a Test Error.) Downtime is calculated as: # Test Errors / # Test Runs |
| % Frustrated | The percentage of test runs that exceeded the Apdex “frustrated” threshold. |
| % Not Frustrated | The percentage of test runs that completed in less time than the Apdex “frustrated” threshold. This is equivalent to: % Satisfied + % Tolerating |
| % Ping Packet Loss | The percentage of pings packets sent which did not receive a response. Calculated as: (# packets received / # packets sent) * 100 |
| % Satisfied | The percentage of test runs that completed in less time than the Apdex “Satisfied” threshold. |
| % Tolerating | The percentage of test runs that exceeded the Apdex “Satisfied” threshold but completed in less time than the “Frustrated” threshold. |
| Apdex | A scoring mechanism that translates performance metrics of diverse applications into generic “User Satisfaction” levels using predefined response time thresholds. You can use default Apdex thresholds or configure your own on a per basis. For more details about Apdex, visit http://www.apdex.org/ |
| Experience Score | A composite metric that captures the overall experience of a user on a scale of 0-100. |
| Ping Round Trip (ms) | Average time between sending a ping packet and receiving a response. |
| Test Time (ms) | One cohesive metric that applies to all test types and indicates the total duration of the test run. Test Time is equivalent to Response, Test Response (Transaction and web tests) and ping RTT (Trace Route tests), and is used when calculating Apdex. Test Time is not available for Request, Host, or Zone charting. |
| Jitter (ms) | Jitter refers to the variation in the forwarding delay of consecutive packets in a stream. |