183
edits
Path measurement: Difference between revisions
Jump to navigation
Jump to search
m
→Measurement statistics: Reformatting headings structure
m (→Path measurement: Drop outdated firmware versions) |
m (→Measurement statistics: Reformatting headings structure) |
||
| Line 102: | Line 102: | ||
|} | |} | ||
=== Measurement === | |||
The '''measurement''' tab show the real-time results of the ongoing measurement. | The '''measurement''' tab show the real-time results of the ongoing measurement. | ||
At the top the current state of the measurement engine and the remote connection is shown. | At the top the current state of the measurement engine and the remote connection is shown. | ||
| Line 115: | Line 116: | ||
* Insufficient memory: Usually may only appear in PCAP analysis mode indicating that the values for packet delay and packet rate are too large. Either reduce the values or use a larger storage devices capable of storing the required data (amount shown in the configuration section) | * Insufficient memory: Usually may only appear in PCAP analysis mode indicating that the values for packet delay and packet rate are too large. Either reduce the values or use a larger storage devices capable of storing the required data (amount shown in the configuration section) | ||
=== Two-Way-Latency === | ==== Two-Way-Latency ==== | ||
The first graph shows the latency measured from the main device to the remote device and back. | The first graph shows the latency measured from the main device to the remote device and back. | ||
| Line 125: | Line 126: | ||
To the left of the graph the statistics for the visible time range is shown, changing the zoom level or time interval will update the values accordingly. | To the left of the graph the statistics for the visible time range is shown, changing the zoom level or time interval will update the values accordingly. | ||
=== One-Way-Latency === | ==== One-Way-Latency ==== | ||
If the path measurement is used on a single device (by selecting the primary device as client device too), the one-way latency is shown for each direction instead of the two-way-latency. | If the path measurement is used on a single device (by selecting the primary device as client device too), the one-way latency is shown for each direction instead of the two-way-latency. | ||
=== Lost packets === | ==== Lost packets ==== | ||
The second and third graph show the number of lost packets in each direction. Lost packets are only accounted for connections that have been seen on both devices. | The second and third graph show the number of lost packets in each direction. Lost packets are only accounted for connections that have been seen on both devices. | ||
| Line 142: | Line 143: | ||
#Capture drops can also occur if the network connection is not capable of transferring the data fast enough. Rule of thumb is that approximately 5% of the total traffic is used for the measurement connection. For example, if the traffic is 500 MBit/s, the measurement requires ~25 MBit/s of bandwidth on the management port. | #Capture drops can also occur if the network connection is not capable of transferring the data fast enough. Rule of thumb is that approximately 5% of the total traffic is used for the measurement connection. For example, if the traffic is 500 MBit/s, the measurement requires ~25 MBit/s of bandwidth on the management port. | ||
=== Monitored packet rate === | ==== Monitored packet rate ==== | ||
The fourth graph shows all packets that are monitored for the path measurement. This will cover all connections that have been seen on both devices. | The fourth graph shows all packets that are monitored for the path measurement. This will cover all connections that have been seen on both devices. | ||
=== IP | === IP addresses === | ||
The second tab shows packet loss information for each pair of IP addresses. This statistic covers all IP connections that has been seen on both measurement sides. The table shows the number of packets that have been counted for each communication pair. Additionally the number of packets seen on the main device and the corresponding packet loss is shown. The same statistics are shown for the client device too. You can click on the IP address to go to the detailed statistics of the IP module to check which kind of traffic was happening for that IP. Two graphs are shown for each IP pair which shows the packet loss for both direction on one graph and the total packets in the second graph. | The second tab shows packet loss information for each pair of IP addresses. This statistic covers all IP connections that has been seen on both measurement sides. The table shows the number of packets that have been counted for each communication pair. Additionally the number of packets seen on the main device and the corresponding packet loss is shown. The same statistics are shown for the client device too. You can click on the IP address to go to the detailed statistics of the IP module to check which kind of traffic was happening for that IP. Two graphs are shown for each IP pair which shows the packet loss for both direction on one graph and the total packets in the second graph. | ||
| Line 154: | Line 155: | ||
For each IP, there is also a link to the IP connections. If enabled, each individual IP connection also stores the latencies for more detailed view. | For each IP, there is also a link to the IP connections. If enabled, each individual IP connection also stores the latencies for more detailed view. | ||
=== Switching graph modes === | ==== Switching graph modes ==== | ||
The toggle buttons above the graphs allow to switch the graph modes from absolute values to relative values. This setting will show the lost packets in relation to the total (monitored) traffic. The second option allows to show | The toggle buttons above the graphs allow to switch the graph modes from absolute values to relative values. This setting will show the lost packets in relation to the total (monitored) traffic. The second option allows to show Mbit/s throughput instead of the packet rate. | ||
== Limitations == | == Limitations == | ||
| Line 162: | Line 163: | ||
There are some limitations about the path measurement: | There are some limitations about the path measurement: | ||
# Due to technical reasons, large clock adjustments cannot be filtered out. So in such cases, a very large two-way-latency is measured. Both devices need not be time synchronized per se, however, considerable time | # Due to technical reasons, large clock adjustments cannot be filtered out. So in such cases, a very large two-way-latency is measured. Both devices need not be time synchronized per se, however, considerable time differentiation must be avoided. This means that time synchronization (e.g. NTP/PTP) should either be enabled or disabled on both devices for best results. Clock differentiation miss-measurements are however one-time events, and will not lead to false values for the following packets. | ||
# The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement. | # The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement. | ||
# NAT setups and different VLAN combinations on main and client are not supported at the moment. Such flows will be accounted as unmonitored flows in the debug view. | # NAT setups and different VLAN combinations on main and client are not supported at the moment. Such flows will be accounted as unmonitored flows in the debug view. | ||