When Old Commands Can’t Keep Up with Your Speed
Imagine your boss just called to nag: “Why is the office network so sluggish?”. By reflex, you type ping 8.8.8.8. A long, endless list of text starts scrolling across your screen. You strain your eyes to see if any time value spikes.
In reality, this approach is exhausting. Micro-spikes in lag that only last 1-2 seconds are incredibly hard to spot if you’re just looking at text. Similarly, when a server suddenly hits a bottleneck, iftop only tells you which IPs are using the most data, but it doesn’t name the exact application “eating up” your bandwidth.
Classic tools like ping, dig, or netstat were born in the era of monochrome monitors. They prioritize being lightweight but lack intuitiveness. To resolve incidents faster, I’ve switched entirely to a trio written in Rust: gping, bandwhich and doggo.
Why Should You Refresh Your Toolkit?
When the network is unstable, the issue usually lies in three blind spots that old tools struggle to describe:
- Latency Fluctuations (Jitter): Ping still responds, but it’s erratic and inconsistent.
- Background Processes: A system update or backup script is hogging the connection.
- Slow DNS Responses: Domains take 2-3 seconds to resolve, causing web applications to hang.
Here is how I use this trio to diagnose system issues in seconds.
1. gping – Visualizing Latency with Real-Time Graphs
Instead of reading numbers, gping draws a graph right in your terminal. You’ll clearly see the spikes when the network lags. I often use it to compare latency between nodes to isolate whether the fault lies with the ISP or internal devices.
Quick Installation
# Use Homebrew (most popular for Linux/macOS)
brew install gping
# Or use cargo
cargo install gping
Real-World Scenarios
To find out if the network is slow due to undersea cables or your home modem, try this command:
gping 1.1.1.1 google.com 192.168.1.1
The screen will display three different colored graph lines. If all three lines spike, your modem or cable is definitely the problem. If only google.com spikes, the issue lies with the international connection.
2. bandwhich – Identifying Bandwidth-Hogging Applications
bandwhich is my go-to tool when I need to find the “culprit” consuming bandwidth. Unlike nload or iftop, it displays details by Process name, Connection, and destination IP.
How to Install
# Install via cargo
cargo install bandwhich
Usage Tips
When the server load suddenly spikes unexpectedly, run:
sudo bandwhich
The interface is divided into three clear columns. You can immediately see if rsync is silently pushing data at 50MB/s, or if a Python bot is making thousands of outgoing requests. Note: You must use sudo so the tool has permission to access the system’s network stack.
3. doggo – A Modern and Clean DNS Client
If you find dig too cumbersome with its long blocks of text, doggo is the answer. It supports colors, an easy-to-read interface, and especially DoH (DNS over HTTPS)—a modern security standard.
Installation
go install github.com/mr-karan/doggo/cmd/doggo@latest
Tips for Using doggo Effectively
To check the MX (Mail Server) records of a domain, simply type:
doggo itfromzero.com MX --human
The results returned will be extremely neat. One feature I really like is the ability to check DNS from multiple servers simultaneously to see if records have finished updating:
doggo google.com @8.8.8.8 @1.1.1.1
If you need to write monitoring scripts, add the --json flag. The returned data will be perfectly structured for other tools to process.
60-Second Troubleshooting Workflow
Instead of fumbling with dozens of commands, I usually apply the following workflow when the network starts “protesting”:
- Launch gping: Check for stability. If the graph shows constant sawtooth patterns, identify the fault in the physical connection.
- Open bandwhich: See if any background apps are hogging all the bandwidth. If you see a suspicious process, use
kill -9to free it up immediately. - Use doggo: Check if slow services are due to DNS resolving to the wrong IP or if the DNS server is responding too slowly (over 500ms).
A small note: bandwhich will consume some CPU resources if your server is handling massive traffic (several Gbps). Therefore, you should only turn it on when needed and close it immediately after.
These tools do not completely replace traditional Linux commands. However, they help you save up to 70% of observation time. Looking at a visual graph is always much more effective than straining your eyes to read dry lines of text in a high-pressure environment.

