HN user

panosv

37 karma
Posts17
Comments23
View on HN

Everyone knows ping. But over the decades, the networking community has quietly built an entire family of specialized variants — each solving a problem that standard ICMP couldn't. A few examples of why you'd reach for something else:

tcping — when firewalls eat your ICMP and you need to test port availability

arping — L2 diagnostics and duplicate IP detection, no IP stack needed

fping — scan a /24 in seconds, all hosts in parallel

OWAMP — when you actually need one-way latency, not just RTT

dnsping — when the slowness lives in your resolver, not the network

I put together a comparison table of the most useful ones, across protocol, OSI layer, platform, multi-host support, and root requirements. The OSI layer column alone tells you a lot — if you're reaching for ping to debug something that lives at L4 or L7, you're probably using the wrong tool.

What about Google? Anyone has any insights on their unit economics since they own the models and the infrastructure (which is also custom TPUs)? Are they doing better or are they in the same money losing business?

That's the point. On the GPU side they use all the 5000+ cores to parallelize the algorithm (they use the hardware to its full potential). On the CPU side they use just one core (at least there is no mention around the cores used on the CPU). It's like saying a Camry beat a Ferrari in maximum speed, but you don't mention that the Ferrari was only in the first gear for that specific race.

You might have seen the recent project on network speed testing on a Raspberry Pi which tweets to Comcast when the speed goes below 50 Mbps. This is an alternative or complementary option.

The Raspberry Pi software is installed as a Debian package. The data is displayed on a dashboard. You can receive alerts by email when the connection goes down, the Ping packet loss goes above x%, you can't access Facebook, or can't resolve times.com. No tweeting capabilities though.

Network Tomography 10 years ago

Hi everyone, I am the author of the post. Network tomography is a very intriguing idea and very promising. However, it hasn't taken off outside the academic/research realm.

I am wondering what networking folks think about it.

The next in line is scheduled Iperf. Right now you can run Iperf manually between two agents or an agent and your own Iperf server. The scheduled Iperf will allow you to run the test periodically (e.g. every 2 hours), or specific times during the day(e.g. 8:00 AM, 2:00 PM, 10:00 PM).

Apart from bandwidth, Iperf will give you jitter and packet loss.

NetBeez makes sure that users on large and distributed enterprise networks have access to the applications and resources they need. As soon as an app or the network connectivity goes down it notifies the network operator.

It works by installing software agents/bots in the network that simulate user behavior. We use Raspberry Pis to host our agent software, because their low-cost, size, and power consumption make it possible to scale to hundreds of agents from a pricing and technology perspective. It does wired and WiFi monitoring.

If you are network engineer and have any Raspberry Pis laying around install an agent on them and play with NetBeez.