Microsoft Ethr: a Go network measurement tool for bandwidth, latency and connection rate

The gap Ethr fills between iPerf3, sockperf and psping

Most engineers end up with three or four network tools installed at once. iPerf3 covers TCP and UDP bandwidth. sockperf or latte covers latency. psping covers Windows-side connection latency. Each has its own flags, its own output format, and its own idea of what a thread means. Ethr's stated goal is to collapse that set into one native Go binary that runs on Windows, Linux and other Unix systems without an abstraction layer like cygwin.

The README is explicit about where the inspiration came from. For bandwidth it is similar to iPerf3, and the README concedes that iPerf3 "has many more options for doing such as throttled testing, richer feature set." Where Ethr claims an edge is thread count: the README says its support for multiple threads "allows it to scale to 1024 or even higher number of connections, multiple clients communication to a single server." For latency it points at latte on Windows and sockperf on Linux as the comparable tools.

The audience is the person who has to answer whether a path is bad in throughput, in connection setup, or in jitter, without installing a different tool for each question. That is a narrower audience than a general benchmarking suite, and the README does not pretend otherwise. It also states that more protocol support is planned rather than present, so anyone evaluating it for HTTP or HTTPS coverage should treat those as listed protocols rather than as fully documented test modes.

How the client and server split actually works

Ethr runs in two modes, and the split is strict. In server mode the binary listens for tests; in client mode it can only talk to an Ethr server. The README states this plainly for the client: "In this mode, Ethr client can only talk to an Ethr server." That is a real constraint. You cannot point an Ethr client at an arbitrary HTTP endpoint and expect a bandwidth number, because the server side has to cooperate.

The exception is the -x flag, which the README uses for tests against external hosts. Examples include measuring TCP connection setup latency to www.github.com at port 443, and ICMP ping latency to the same host. That path bypasses the Ethr server entirely, which is why it works against a host that has never heard of the tool.

Server mode binds to a local IP and a port. The README gives -ip for binding a specific address for TCP and UDP tests and -port with a default of 8888. Client mode takes -c <server>. The measurement type is selected with -t: bandwidth by default, c for connections/s, p for packets/s, pi for ping latency, and mtr for a MyTraceRoute-style run. Protocol selection is separate, via -p tcp, -p udp or -p icmp, and address family via -4 or -6.

Logging is on by default. The README notes that logging to file is enabled unless you pass -no, and that the default filenames are ethrs.log in server mode and ethrc.log in client mode. That default matters on a long-running server, because nothing in the README describes rotation. The repository layout backs this up: log.go sits at the top level next to client.go and server.go, so logging is a first-class part of the binary rather than an add-on, and the text UI is implemented separately in ui.go, clientui.go and serverui.go.

Installing Ethr and running a first bandwidth test

The README points at the GitHub releases page for prebuilt binaries, with a separate zip per platform. On Linux the documented sequence is a download and an unzip:

wget https://github.com/microsoft/ethr/releases/latest/download/ethr_linux.zip
unzip ethr_linux.zip

Windows uses the same URL pattern with ethr_windows.zip and Expand-Archive, and macOS uses ethr_osx.zip. Building from source needs Go 1.11 or higher according to the README, and go-modules manage the dependencies. The repository's go.mod declares go 1.25 and pulls in golang.org/x/net and golang.org/x/sys as direct dependencies, plus termbox-go and go-runewidth for the text UI.

git clone https://github.com/Microsoft/ethr.git
cd ethr
go build

The README adds a caveat for anyone cloning into the $GOPATH/src tree: invoke go with GO111MODULE=on. There is also a Docker path. The Dockerfile is a golang:1.25 base that copies the tree into /app and runs go build, and the Makefile exposes a build-docker target that writes the binary into /out:

docker build -t microsoft/ethr .
docker run -e GOOS=linux -v $(pwd):/out microsoft/ethr make build-docker

For a first real test, start the server on one machine and point the client at it. The README's own examples use localhost for the default bandwidth measurement:

ethr -s
ethr -c localhost -n 8

The first command starts the server with no UI. The second runs the default bandwidth test over eight threads. If you want the server's text UI, add -ui to the server command; the README shows that as a separate invocation. To run on a non-default port, pass -port on both sides, for example -port 9999, and remember that the client must match. Arch users can install through the AUR with yay -S ethr, which the README documents as a supported path.

Privileges, firewalls and the ICMP tests that fail silently

The ICMP and trace-route tests are the part most likely to waste an afternoon. On Linux the README states that ICMP ping, ICMP/TCP trace route and MyTraceRoute require privileged mode via sudo. That is not a suggestion; without it the tests do not produce the measurement you asked for. The README's own ICMP examples are written with sudo in front of them.

Windows has a different obstacle. The README says ICMP-related tests require ICMP to be allowed through the firewall, and gives the PowerShell commands to create inbound allow rules for ICMPv4 and ICMPv6. It adds a qualifier worth reading twice: use this only if the security policy of your setup allows it. Separately, the README notes that TCP-based trace route and MyTraceRoute need Administrator mode on Windows, otherwise Ethr will not receive the ICMP TTL exceeded messages that the trace depends on. That failure mode is quiet. You get a trace with missing hops rather than an error telling you why.

This is the clearest case where Ethr is the wrong tool for a locked-down environment. If you cannot open ICMP or cannot run as Administrator, the latency and path-discovery features are largely unavailable, and you are left with the TCP and UDP measurements only. The platform-specific code in the repository, split across plt_windows.go, plt_linux.go and plt_darwin.go, is where that privilege handling lives, which is also why behaviour differs between operating systems rather than being uniform.

Where Ethr is weaker than the tools it borrows from

The README does the honest thing and names the gap itself. iPerf3 has throttled testing and a richer option set for bandwidth work; Ethr does not claim to match it there. If your test requires a specific target bitrate rather than a best-effort measurement, iPerf3 remains the tool for that job, and the difference is not cosmetic. Throttled testing changes what you are measuring: a shaped flow exercises queueing behaviour that a full-speed flow does not.

The second limitation is documentation depth rather than capability. The README covers flags thoroughly and the complete command line is listed, but operational questions go unanswered. There is no documented log rotation despite file logging being on by default. There is no documented guidance on running the server safely on a shared network, and no documented rollback procedure for the NuGet packaging path the README describes. The repository does carry a SECURITY.md, so the project has a disclosure channel, but the README itself does not describe hardening.

The third limitation is the client-server coupling. Because an Ethr client can only talk to an Ethr server for the server-mediated tests, you cannot measure a path where you control only one end unless the other end is willing to run the binary. The -x path partly works around this for connection setup latency and ICMP, but the bandwidth and packets/s measurements depend on a cooperating peer.

A fair alternative comparison: sockperf on Linux and latte on Windows are latency-focused, and they go deeper on latency behaviour than Ethr's latency modes. Ethr's advantage is that the same binary also gives you bandwidth and connection rate, so you trade depth in one dimension for coverage across several. If latency tail behaviour is the only question you have, the specialised tools remain the better choice.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-07-03. That is recent enough that the codebase is moving, but the release history tells a different story about tagged versions. The most recent release listed is v1.0.0 from 2020-12-05, preceded by v0.9.0 in November 2020 and v0.2.1 in January 2019. So there is a real gap between commit activity and tagged releases, and anyone pinning to a release artifact should expect the binary to lag the source tree. The README's install instructions point at the releases page, which means the zip you download corresponds to that tagged history rather than to the latest commit.

On cost, the dependency list in go.mod is short: four direct dependencies, two of them indirect. That is a small surface to audit and a small surface to break on a Go toolchain bump. The go.mod declares go 1.25 while the README still says Go 1.11 or higher is required for building from source, so the README's minimum is stale relative to the module file. Build with the toolchain the module declares, not the one the README names.

The licence is MIT, stated in the repository and in the LICENSE file. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice preserved. It offers no patent grant and no warranty, which is typical for the licence but worth knowing if you are embedding the binary in a product. The README's NuGet publishing section shows ethr.exe being packed via ethr.nuspec and uploaded to nuget.org, so the MIT terms apply to that distribution path as well. None of this is legal advice; read the LICENSE file in the repository for the actual terms.

Text UI, logging and the operational details that bite later

The -ui flag on the server turns on a text UI, which the repository implements through termbox-go and go-runewidth. That is the whole of the UI story in the README. There is no documented way to export UI output to a file, and no documented format for the metrics the UI renders. If you need machine-readable results for a dashboard, the README does not describe one, and the log files are the only documented artifact.

Those log files deserve attention before you deploy. Logging to file is enabled by default, the server writes ethrs.log and the client writes ethrc.log, and you can change the name with -o or turn logging off entirely with -no. The README documents -debug for more verbose logging output. What it does not document is what happens when the log file grows, because nothing in the README describes rotation or a size cap. On a server left running for weeks, that is an operational detail you have to handle outside the tool.

The address family flags are worth setting deliberately. The README provides -4 and -6 to force IPv4 or IPv6. Leaving them unset on a dual-stack host means the measurement may not exercise the path you care about, and the README's own examples pass -4 explicitly for the connection setup latency and ICMP tests. Follow that habit rather than relying on defaults.

One more thing the repository makes visible but the README does not discuss: the build pipeline. A .travis.yml and travis_build.sh sit at the top level alongside a Makefile that also offers fmt and lint targets. Anyone forking Ethr inherits that build expectation, and gofmt plus golint are part of it.

Editorial conclusion

Adopt Ethr when you want one binary that covers bandwidth, connections/s, packets/s and latency across TCP, UDP and ICMP, and when you need to push a test past a few hundred connections with the -n thread flag. Do not adopt it if you need iPerf3's throttled testing or a richer option set, and do not expect the README to explain rollback, server hardening or log rotation. Before trusting a number, verify the server port actually matches on both ends, check that ICMP tests run with the privileges the README lists for your platform, and confirm the release zip you downloaded matches the platform you are measuring from.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/ethr on GitHub
4. README
5. Releases