Network Performance
The Network page is your active network performance and observability center. It measures your server’s real-world download and upload throughput, round-trip latency, jitter, and packet loss — either on demand or automatically on a schedule — and keeps a history so you can spot degradation over time rather than guessing from a one-off test.
Find it in the sidebar under System > Network. A latest-result tile also appears on the System Dashboard and deep-links here.
Network Performance is an administrator feature. Only users with the administrator role can open the Network page, run tests, or change the schedule. Network performance is a server-operator concern, not a per-user setting.
The module uses librespeed-, which is installed as a base tool on every QuickBox server, plus a standard ping latency sub-test. There is no separate package to install and no qb command to run — it is a native dashboard feature.
Key features
On-demand testing
Run a test now with a live gauge and a streaming log feed as throughput and latency are measured
Scheduled testing
Enable automatic tests on a fixed interval so network performance becomes an ongoing operational signal
Historical trends
Time-series charts of download, upload, and latency across 24 hours, 7 days, 30 days, a year, or all time
Latest-result KPIs
At-a-glance cards for the most recent download, upload, ping, and jitter values
Exportable data
Export the history view as CSV or JSON, or save the trend chart as a PNG image
Rich result detail
Each test records the test server, ISP, and whether it was triggered manually or by the schedule
Running an on-demand test
- Open System > Network from the sidebar.
- In the Run Test Now panel, start the test.
- A live gauge and log feed show progress as the test runs — first the throughput measurement via
librespeed-, then the latency sub-test.cli - When the test completes, the latest-result KPI cards and the history chart refresh automatically with the new data point.
A test typically takes well under a minute. The throughput measurement reaches out to a LibreSpeed test server — librespeed- automatically selects the nearest node from LibreSpeed’s public, multi-region server network, so each server tests against a server close to it. A short ping burst measures latency, jitter, and packet loss in parallel.
The download and upload figures come from librespeed-, which auto-selects the nearest server from LibreSpeed’s public server network and reports download, upload, and ping. Latency, jitter, and packet loss come from a separate ping burst (10 packets) so the values are richer than the single ping figure the speed test alone returns. If the latency sub-test cannot run, the throughput result still stands.
Reading test results
Every completed test is stored with the following fields:
| Field | What it shows |
|---|---|
| Download | Measured download throughput in Mbps |
| Upload | Measured upload throughput in Mbps |
| Ping | Average round-trip latency in milliseconds |
| Jitter | Variation in latency (lower is more stable), in milliseconds |
| Packet loss | Percentage of ping packets that were dropped |
| Test server | Name and host of the nearest LibreSpeed server the measurement auto-selected |
| ISP | The internet service provider detected for the test |
| Trigger | Whether the test was started manually or by the schedule |
| Timestamp | When the test ran |
The most recent values are summarized in the KPI cards at the top of the page.
Scheduled testing
Scheduled testing turns a one-time diagnostic into a continuous operational signal. In the Schedule panel you can configure:
| Setting | What it controls |
|---|---|
| Enabled | Whether automatic tests run at all. Disabled by default — no scheduled tests until you turn it on. |
| Interval (hours) | How often a scheduled test runs, in hours. Accepts 1 through 168 (a full week). |
| Retention (days) | How long results are kept before older entries are pruned. Set to 0 to keep history forever. |
The schedule panel shows the last scheduled run and the next scheduled run so you always know where the cadence stands. Scheduled tests appear in the history alongside manual ones, tagged by their trigger source.
The schedule lives in the dashboard’s configuration database, so it persists across restarts. There is no cron entry or config file to edit by hand.
Historical tracking and trends
The history panel charts your results over time, with download and upload throughput on one axis and latency on another. Use the range picker to switch the window:
| Range | Use it to |
|---|---|
| 24 hours | See recent fluctuation and confirm a problem you just noticed |
| 7 days | Spot a pattern across a typical week (the default view) |
| 30 days | Track performance trends across a billing cycle |
| 1 year | Review long-term capacity and seasonal patterns |
| All time | See the full recorded history |
Load older entries with the load more control, and export the current view as CSV or JSON, or save the trend chart as a PNG image for reports or support tickets.
Interpreting results
A few things to keep in mind when reading the numbers:
- Measured speed is usually lower than your advertised plan. Speed tests are best-effort against a remote server and are affected by routing, server load, time of day, and other traffic on your link. A measurement somewhat below your ISP’s headline rate is normal.
- Watch trends, not single tests. One slow result during a busy period is noise. A sustained downward trend across many tests is a signal worth investigating.
- Latency and jitter matter for streaming. Low, stable latency (low jitter) matters more for a smooth streaming experience than raw throughput once your download speed is comfortably above your content bitrate.
- Packet loss should be near zero. Consistent non-zero packet loss points to a network problem worth raising with your host or ISP.
Troubleshooting
| Symptom | What it means / what to do |
|---|---|
| Test fails with a *librespeed-cli not found* message | librespeed- is installed as a base tool on every QuickBox server, so this is rare. If it appears, the tool may have been removed manually — reinstall it and run the test again. |
| Latency sub-test shows as unavailable | The ping burst could not complete (for example, outbound ICMP is blocked). The throughput result still stands; only the jitter and packet-loss figures are missing. |
| Measured speed looks far below your plan | This is often normal — see Interpreting results above. Run a few tests at different times and compare the trend before concluding there is a problem. |
| A test seems stuck | Tests have a built-in timeout and will fail cleanly rather than hang indefinitely. The result is recorded as failed with an error message you can read in the log. |
Best practices
Do
- Enable scheduled testing so you build a performance baseline instead of only testing when something already feels wrong
- Choose an interval that fits your needs — every few hours is plenty for trend tracking without over-testing
- Set a sensible retention period if you do not want history to grow forever
- Export a CSV or chart PNG when opening a support ticket so the evidence travels with the request
- Compare results across several tests before acting on a single slow reading
Don't
- Don't run tests back-to-back in a tight loop — each test consumes real bandwidth and can briefly affect other traffic
- Don't treat one slow result as proof of a problem; look at the trend
- Don't expect measured speed to exactly match your advertised plan
FAQ
Related pages
The passive vnStat layer that keeps bandwidth tracking accurate as your interfaces change — complements active performance testing
Real-time CPU, memory, disk, and network telemetry plus the latest-network-result tile that deep-links here
Dashboard configuration including network interface selection
Join the Community
Media server operators sharing configs, getting support, and shaping the future of QuickBox Pro.
- Dedicated Support
- Feature Previews
- Community Configs
- Active Discussions