1,775
edits
No edit summary |
No edit summary |
||
Line 129: | Line 129: | ||
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 if that happens, a very large two-way-latency is measured. Both devices does not need to be time synchronized but large adjustments shall not happen. That means that time synchronization (for example via NTP) should be enabled on both devices or disabled on both devices for best results. However, such clock adjustment miss-measurements are one-time events and will not lead to false values for the following packets. | '''#''' Due to technical reasons, large clock adjustments cannot be filtered out so if that happens, a very large two-way-latency is measured. Both devices does not need to be time synchronized but large adjustments shall not happen. That means that time synchronization (for example via NTP) should be enabled on both devices or disabled on both devices for best results. However, such clock adjustment miss-measurements are 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. | |||
'''3.''' NAT setups and different VLAN combinations on master and client are not supported at the moment. Such flows will be accounted as unmonitored flows in the debug view. | '''3.''' NAT setups and different VLAN combinations on master and client are not supported at the moment. Such flows will be accounted as unmonitored flows in the debug view. |
edits