Troubleshooting
Fast Speed Test but Slow Downloads?
Compare transfer units, request timing, app limits and controlled downloads to investigate a fast speed test alongside slow file transfers.
A fast speed test does not promise the same rate for every download. VMAXCHECK uses M-Lab NDT, which measures a single data stream to a test server. A file can use a different destination, route and application. The result describes that test at that time; it does not rule out problems with your provider or another route.
Check the units and the slow stage
- Mbps means megabits per second; MB/s means megabytes per second. Eight bits make one byte, so 100 Mbps is mathematically 12.5 MB/s and 10 MB/s is 80 Mbps. Protocol overhead reduces usable file throughput. MB and MiB are different size units too.
- A decimal 1 GB file would ideally take 80 seconds at a constant 100 Mbps. That excludes waiting and overhead; it is a calculation, not a download-time guarantee.
- Separate waiting to start, receiving data, and subsequent writing, verification or installation. A progress bar can include several stages. Slow installation does not directly measure your connection speed.
- For a browser download, optionally select the request in Edge DevTools Network and inspect Timing. Waiting (TTFB) includes round-trip and server preparation time; Content Download covers receiving the response. A cache or service-worker response changes the comparison. One timing value does not identify a culprit.
Record a comparable baseline
Note time, device, app version, authorised file source, size, receive rate with its unit, and the stage currently running. Include Wi-Fi location or Ethernet, VPN or proxy use, and your own concurrent transfers. Run the speed test between downloads, never alongside them. Compare close together on the same device under the same conditions; merely using results from the same hour is insufficient.
Use comparisons that narrow the possibilities
- Same file, source and device: compare Wi-Fi with Ethernet when available. A repeatable improvement points toward the wireless part, but does not prove a broken router. A cable into a mesh node may still rely on wireless backhaul.
- Temporarily pause other large transfers you control and repeat. Improvement is consistent with competing traffic, not proof of a provider fault or an inadequate package.
- Compare a similarly sized file from another trusted, authorised source. Destination, route, cache and transfer method may differ; this does not automatically separate them. Avoid unknown download helpers or dubious file copies.
- Where permitted, try the same service on another suitable device or its official app. Observe reception separately from CPU and disk activity. Changing client or app changes several conditions, so a difference does not prove a defective disk.
Check the affected app's documented download limits. For example, the OneDrive desktop sync app offers rate options in Sync and back up and Advanced settings; an organisation may manage them. That limit concerns that app. Even if several downloads are slow and NDT is fast, destinations, routes, load and timing still matter. VPN or proxy use changes the path; its presence alone does not establish the cause.
Make one change supported by the evidence
- Adjust a confirmed app limit only when you are authorised to manage it, and record its previous value. Respect managed settings and involve the administrator for work or school devices.
- If the delay occurs during writing or verification, check free storage and the app's official guidance. Use vendor update procedures. Keep antivirus and other protections enabled during a general speed investigation.
- For one affected source, check its service status and official download procedure. For several affected services, collect the comparisons for your provider or administrator. This mismatch alone does not justify DNS changes, registry edits or a router purchase.
- After one change, repeat the same comparison with comparable file and load conditions. Restore ineffective changes. Save events and results before any vendor-recommended restart.
Send support a private table of time, source, connection, actual receive rate, stage and comparison results. Remove credentials, personal filenames and URL access tokens. Even a HAR exported as sanitized can retain private URLs or content; inspect it before sharing.