Endpoint selection
Raftaar attempts Measurement Lab’s NDT7 service first. M-Lab discovers nearby available capacity and runs download and upload measurements over secure WebSockets.
If M-Lab cannot complete a test, Raftaar tries browser-compatible endpoints returned by the Raftaar configuration API. Cloudflare and AppsGhar endpoints are built in as final fallbacks.
- Primary: M-Lab NDT7
- Fallbacks: API-configured browser endpoints
- Built-in fallbacks: Cloudflare and AppsGhar
Download and upload
NDT7 measures each direction over a short transfer window and reports application-level goodput. HTTP fallbacks use concurrent transfers and increasing payload sizes to make efficient use of both mobile and broadband connections.
Mbps means megabits per second. It is calculated from completed measurement bytes and elapsed time; it is not the same as megabytes per second shown by some file download tools.
Ping and jitter
For NDT7, Raftaar derives latency from the server’s transport measurements. For HTTP fallbacks, it measures ten small round trips. Ping is the average delay; jitter is the average absolute change between consecutive samples.
Why results vary
A result reflects the device, browser, Wi-Fi or mobile radio, ISP, route and selected server at that moment. Other traffic, VPNs, congestion, power saving and hardware limits can all change the outcome.
Raftaar results are estimates for troubleshooting and comparison. They are not a certification of an ISP plan or a legal measurement.
Data and privacy
Test payloads are generated bytes, not personal files. M-Lab publishes NDT measurement data and connection metadata, including public IP and timestamp, under its research data policy. Raftaar asks for acknowledgment before beginning.
Completed results are saved locally first and submitted to AppsGhar with a random installation ID. Raftaar does not place your public IP inside that result payload, although contacted servers can see it as part of normal internet communication.