Home | Contact
whichnas.com

Automate Speed Tests and Bandwidth Logging on Your NAS

Network-attached storage owners in Australia often work with patchy NBN performance, especially during peak evening hours when households in Melbourne, Brisbane and Adelaide settle in for streaming. Running scheduled network checks from the NAS itself is a reliable way to capture how much throughput your connection actually delivers hour after hour, instead of trusting a single ad-hoc test. Tools that quietly log WAN bandwidth from inside the home give you a timeline you can correlate with work calls, gaming sessions or backups to Wasabi, Backblaze or an off-site rsync target.

The setup process is straightforward once you pick a measurement tool, decide where to store the output, and wire it into the scheduler that ships with your NAS operating system. The walkthrough below covers the most common toolchains for Synology DSM and QNAP QTS, the formats you can use for log storage, and ways to turn raw numbers into actual diagnostics across a full quarter of data.

Choosing a Measurement Tool That Fits Your NAS

Three tool families dominate NAS-friendly bandwidth testing. The first is the speedtest-cli Python utility, originally forked from the Ookla Speedtest.net client and still maintained as an open source project. It contacts the closest speedtest server, which in Australia usually means a node in Sydney, Melbourne or Perth, and reports download, upload and idle latency in a single pass. The second is iperf3, which is more useful for measuring LAN throughput between the NAS and another device on the same switch, and which gives you precise control over TCP window sizes and parallel streams. The third approach is a custom shell pipeline that uses curl or wget to download a known file from a fixed mirror, parsing the bytes-per-second figure with awk or jq.

Tool Best use case Output detail Synology DSM support QNAP QTS support
speedtest-cli WAN bandwidth to nearest test server Download, upload, latency, server ID Available via Package Center community source or python pip Available via App Center or ipkg
iperf3 LAN throughput between NAS and a peer Streams, retries, jitter, CPU usage Native binary in many community packages Native binary on most firmware images
curl-based fetch Lightweight, no dependencies Raw bytes/sec to a fixed URL Native curl in DSM Native curl in QTS

For most readers chasing a record of how an NBN 50 or NBN 100 plan performs, speedtest-cli is the default. Reserve iperf3 for situations where you suspect the NAS Ethernet port, switch port or cabling is the bottleneck rather than the ISP link, since the two tests measure different layers of the network stack.

Scheduling Bandwidth Tests on Synology DSM

DSM exposes scheduling through Control Panel → Task Scheduler → Create → Scheduled Task → User-defined script. The interface accepts any bash or sh script stored on a volume, which means the practical workflow is to drop a small shell file into a shared folder such as /volume1/scripts/bandwidth_test.sh, mark it executable over SSH, and then call it from the scheduler. The trigger can be set to run every fifteen minutes during business hours, hourly overnight, or once a day, with separate tasks often used so you can capture weekday and weekend behaviour independently.

Time zones matter here. Synology hardware shipped through Australian retailers such as JB Hi-Fi or Mwave arrives configured for AEST by default but does not always switch to AEDT on the right day if NTP is misbehaving. Open Control Panel → Regional Options → Time Zone and confirm the zone reads (UTC+10:00) Canberra, Sydney, Melbourne before saving your task, or the timestamps in your logs will drift by an hour twice a year. Logging in as root through SSH during the initial setup also lets you confirm the script runs end-to-end and that the destination CSV is being written, which avoids silent failures later.

Scheduling Bandwidth Tests on QNAP and QuTS hero

QNAP firmware exposes a similar scheduler under Control Panel → System → Scheduled Tasks, with separate tabs for jobs that run as root and jobs that run as a specific user. Container Station also opens a Docker path for users who prefer running speedtest-cli inside a small Linux container, which keeps Python dependencies isolated from the host firmware. The QNAP approach is similar to DSM at its core, but the manufacturer ships HybridMount and a few other network tools in the App Center that can be reused as part of the measurement pipeline if you already back up to a cloud target.

Australian buyers often pick QNAP through retailers such as Umart, Centre Com or Scorptec, and warranty handling for these units is processed locally rather than through international RMA. Worth keeping in mind: when the unit is replaced, any cron-style scripts living on the original system volume need to be exported beforehand. A common pattern is to keep the speedtest script and any helper binaries under /share/CACHEDEV1_DATA/scripts/ so they survive a firmware reset and can be re-deployed through a single rsync push from another machine on the home network.

Storing, Parsing and Using the Test Results Over Time

Plain CSV remains the easiest format because every spreadsheet and dashboard tool can read it, and writing a one-line append with echo "$date,$dl,$ul,$ping" >> /volume1/monitoring/bandwidth.csv is enough for a year of hourly samples to weigh in at under two megabytes. SQLite adds the ability to query weekly averages without importing into another tool, and a dockerised InfluxDB plus Grafana stack gives you a live graph but at the cost of more storage and more moving parts. The Australian Privacy Principles do not treat home broadband measurements as personal information, but it is still sensible to keep the CSV on a private volume rather than a publicly shared folder, especially if your NAS also hosts Plex or household backups.

A second practical consideration is server selection. Speedtest.net will often pick a Sydney node for east-coast connections and a Perth node for Western Australia, which produces results that are not directly comparable across regions. Pinning the test to a specific server ID with the --server flag, or pointing curl at a stable mirror run by an Australian operator such as AARNet or by a public CDN with a Sydney edge, gives a more honest picture. Adding the server name as a column in the log makes long-term comparisons fair and prevents a noisy reroute from quietly shifting your reference point.

Once the data is being collected, a few simple queries reveal patterns. Plotting the upload column against time of day shows whether your NBN link throttles during the 7pm to 11pm busy window that ACCC Measuring Broadband Australia reports have flagged for years. Comparing weekday and weekend curves exposes whether your upload suffers more when neighbours are working from home, and cross-referencing latency against storms or planned NBN maintenance notifications can confirm whether packet loss is local or upstream. Homes wired with fibre-to-the-node often see slower upload speeds after a few days of heavy rain, especially in older suburbs of Hobart or Brisbane where the copper run between premises and the node is long, and a month of logged samples is usually enough to make that case to your provider, whether that is Telstra, Optus, Aussie Broadband or TPG.

Practical Recommendations for Reliable Logging

If you want a deeper comparison of NAS models that handle cron-style workloads comfortably, or tips on pairing bandwidth logs with container-based dashboards, browse the rest of the WhichNAS site for compatible Synology and QNAP hardware and the kind of monitoring stack each one can run without breaking a sweat. Pick the toolchain that matches your operating system, leave it to log for a fortnight, and the patterns will start to write themselves.