Documentation
¶
Overview ¶
ndt7-client is the ndt7 command line client.
Usage:
ndt7-client [flags]
The `-format` flag defines how the output should be emitter. Possible values are "human", which is the default, and "json", where each message is a valid JSON object.
The (DEPRECATED) `-batch` flag is equivalent to `-format json`, and the latter should be used instead.
The default behavior is for ndt7-client to discover a suitable server using Measurement Lab's locate service. This behavior may be overridden using either the `-server` or `-service-url` flags.
The `-server <name>` flag specifies the server `name` for performing the ndt7 test. This option overrides `-service-url`.
The `-service-url <url>` flag specifies a complete URL that specifies the scheme (e.g. "ws"), server name and port, protocol (e.g. /ndt/v7/download), and HTTP parameters. By default, upload and download measurements are run automatically. The `-service-url` specifies only one measurement direction.
The `-no-verify` flag allows to skip TLS certificate verification.
The `-scheme <scheme>` flag allows to override the default scheme, i.e., "wss", with another scheme. The only other supported scheme is "ws" and causes ndt7 to run unencrypted.
The `-timeout <string>` flag specifies the time after which the whole test is interrupted. The `<string>` is a string suitable to be passed to time.ParseDuration, e.g., "15s". The default is a large enough value that should be suitable for common conditions.
The `-upload` and `-download` flags are boolean options that default to true, but may be set to false on the command line to run only upload or only download.
The `-profile` flag defines the file where to write a CPU profile that later you can pass to `go tool pprof`. See https://blog.golang.org/pprof.
Additionally, passing any unrecognized flag, such as `-help`, will cause ndt7-client to print a brief help message.
JSON events emitted when -format=json
This section describes the events emitted when using the json output format. The code will always emit a single event per line.
When the download test starts, this event is emitted:
{"Key":"starting","Value":{"Test":"download"}}
After this event is emitted, we discover the server to use (unless it has been configured by the user) and we connect to it. If any of these operations fail, this event is emitted:
{"Key":"error","Value":{"Failure":"<failure>","Test":"download"}}
where `<failure>` is the error that occurred serialized as string. In case of failure, the test is over and the next event to be emitted is `"complete"`
Otherwise, the download test starts and we see the following event:
{"Key":"connected","Value":{"Server":"<server>","Test":"download"}}
where `<server>` is the FQDN of the server we're using. Then there are zero or more events like:
{"Key": "measurement","Value": <value>}
where `<value>` is a serialized spec.Measurement struct.
Finally, this event is always emitted at the end of the test:
{"Key":"complete","Value":{"Test":"download"}}
The upload test is like the download test, except for the value of the `"Test"` key.
Exit code ¶
This tool exits with zero on success, nonzero on failure. Under some severe internal error conditions, this tool will exit using a nonzero exit code without being able to print a diagnostic message explaining the error that occurred. In all other cases, checking the output should help to understand the error cause.
Source Files