Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| en:dpi:qoe_analytics:cases:network_health:full_netflow_analytics [2025/10/31 11:53] – elena.krasnobryzh | en:dpi:qoe_analytics:cases:network_health:full_netflow_analytics [2025/12/11 10:15] (current) – created elena.krasnobryzh | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| {{indexmenu_n> | {{indexmenu_n> | ||
| - | ====== | + | ====== |
| - | <note important> | + | <note important> |
| - | The DPI exports [[en: | + | The simplest |
| - | The statistics record latency for each protocol, linked | + | |
| - | Required steps to investigate: | + | Action: |
| - | - Go to QoE Analytics → Subscribers → Netflow | + | - Go to the section |
| - Create a filter where: | - Create a filter where: | ||
| - | | + | |
| - | * Specify | + | * indicate the average speed to make a sample of subscribers actively |
| - | * Specify | + | * specify |
| + | |||
| + | {{: | ||
| + | |||
| + | It is recommended to work with subscribers who have an average (and even better median) RTT of more than 100 in 24 hours. This can be done by: | ||
| + | - Upload data daily to your database via the API or directly from Click House QoE. | ||
| + | - Make a trigger in a graphical interface with specified parameters. | ||
| - | {{ : | + | When processing, it is important to consider the following factors: |
| + | - It is worth checking the geographical distribution of the “problem” unloading. “Accuracy” usually occurs due to network congestion or an old switch, the problem can be fixed on the operator’s side. It happens that a “bad” area is connected by outdated technology (DSL or radio access), then a bad RTT is no longer a bug, but a feature. | ||
| + | - The subscriber may not experience discomfort due to the delay (and speaks directly about it if asked by phone), for example in cases of: | ||
| + | * IoT devices are working, they may have a weak signal | ||
| + | * Works on outdated equipment and does not expect miracles | ||
| + | * Do not use online services | ||
| + | - Problems in Wi-Fi networks can occur due to: | ||
| + | * Noisy Wi-Fi range 2.4 in an apartment building | ||
| + | * router | ||
| + | * complex topology or large size of the apartment / house | ||
| + | - Sometimes it is impossible to determine the host where the subscriber has contacted with a high RTT.\\ | ||
| + | * IP | ||
| + | * http protocol | ||
| + | * No SNI. | ||
| + | - In addition to RTT, you can use the % retransmit metric when searching for problem subscribers. If for a long time (>30 minutes) there is a significant excess of the background value for retransmits (usually 4-5%), this is a sign of degradation of the subscriber’s service. It is not recommended to use retransmitts without RTT, there is a high probability of false positives. | ||
| - | Interpreting the resulting statistics: | + | {{:en: |
| - | {{ :en: | + | Example of a request to the database: |
| + | {{: | ||
| - | * The filter identified 25 potential clients who may have access quality issues. | + | Parameters |
| - | * Detailed latency information for these clients can be viewed | + | '' |
| - | * Using the megaphone icon, they can be added to a __[[en:dpi:dpi_components: | + | '' |
| - | * The report can be exported in a convenient format. | + | '' |