• Packet Loss test emulates a G.711 VoIP call to the configured target for 30 seconds in each direction using an 87 Kbps stream and 218 byte payload at 50 packets per second. Ideally packet loss should be 0. Packet loss in the upload (from agent to cloud) direction would be characterized by the distant party hearing audio anomalies, and packet loss in the download direction would be characterized by the local party (where agent is deployed) hearing audio anomalies. Occasional packet loss well under 1% is fairly normal, but single-digit or especially double-digit packet loss can point to severe quality issues. This test is especially useful to spot patterns, such as increased bi-directional packet loss for a business during working hours, or increased download packet loss for a home broadband connection during prime-time TV hours.
 
  • UDP Jitter test performs both client to server (agent to cloud) and server to client (cloud to agent) jitter measurements according to RFC 3550 by sending a series of 20 message pairs back and forth between agent and target. Ideally jitter will be under 20ms or even 10ms. Many factors including the jitter buffers on the end devices will impact at what level of jitter the user will see or hear any video or audio issues.
 
  • Round Trip Time to Target test performs 2 different tests from agent to target. First it performs a series of 20 pings to the target and then it performs a UDP latency test by sending a fixed byte payload back and forth between agent and target 20 times. The averages of each are then plotted on the graph. For real-time media such as voice and video calls ideally these times would both be 300ms or less. This test is useful because it compares how the network path treats ping (ICMP) packets as compared to UDP based packets, especially since network providers typically configure their equipment to deprioritize ping during periods of network congestion. Under normal circumstances the ping results should be slightly lower than UDP results. This is because while ping is done at the network layer, the UDP test is done between two Firebind agents at the application layer and hence requires additional processing time on the cloud-based agent.
 
  • Ping test performs a series of 20 pings to the configured ping target and then plots the average of the 20 round trip times. There are two primary use cases: [1] pinging of the agent host default gateway (the home/office router/CPE device) or [2] pinging of the ISP first hop router. Pinging the default gateway can be helpful to troubleshoot LAN related issues, especially if the agent is operating on a host that is connected via WiFi. Pinging the first hop router can be helpful to get a more detailed perspective on the connection between the agent site and the ISP's infrastructure, also known as the "last-mile."
 
  • HTTP test performs an HTTP GET for the base page of the configured URL, measuring response time. The response time is a function of both network latency from agent to the distant HTTP server as well as the time it takes the distant HTTP server to process the request. Ideally this time should be several hundred milliseconds or less and remain relatively constant. Spikes in this chart could indicate network issues but absent any other sign of network issues in the other charts, the spikes are more likely processing time delays on the HTTP server itself.
 
  • DNS Response time test performs a DNS lookup to the configured domain name using both the DNS server configured on the agent host operating system as well as to Google's free public DNS server at IP address 8.8.8.8. Ideally response times would be well under 100ms. The comparison of the two different DNS servers can be helpful to determine if there is a problem with the agent host DNS server, especially if the DNS response time for the agent host DNS lookup spikes while the Google DNS lookup remains flat.