Funny timing of this, just last night I experimented with AI building an "ip intelligence" tool that includes a fast traceroute function and a bunch of IP information (ASN, organization, geolocation, CIDR info, DNSBL, reverse IP... mtr is my go-to for network traces, but (given root permissions) the trace it'll run in less than a second.
>Many routers deprioritize or drop ICMP to save CPU.
Not exactly.
Most big routers have ASICs (custom silicon) that can handle the bulk of routing decisions, like an interface card will have a chip that can directly determine where a packet needs to go and forwards it there. These are extremely fast, but limited, and are called "fast path".
Aside: Too many ACLs is a common way that packets fall off the fast path, and is why routers on the public Internet will happily forward along bogon traffic that by it's very nature is just wasting bits on the pipes.
There are some things that the fast path cannot handle, and generating ICMP TTL exceeded messages is one of them. Those go over to the router CPU, which historically has been insanely underpowered. Back when I was doing more routing it was common to have host CPUs in the multi-GHz range with multiple cores, but routers of a similar class would have a 100MHz MIPS CPU.
That's why, as the article goes on to explain, "*"s in the traceroute may not indicate a problem. It's not necessarily a literal deprioritization of ICMP.
If you ever see packet loss in a trace at one step but the steps after it aren't showing it, you can ignore that packet loss, it's likely a CPU limitation on a busy router.
> If you ever see packet loss in a trace at one step but the steps after it aren't showing it, you can ignore that packet loss, it's likely a CPU limitation on a busy router.
Trippy now includes [0] forward loss (Floss) and backward loss (Bloss) _heuristics_ to help surface such behaviour.
The idea was inspired by our previous discussion [1] on the topic on HN some time ago!
These columns are experimental and so not shown by default but can be enabled [2].
a blog about traceroute in 2026. imagine that. hard to believe it could possibly be of any interest at all, especially written by someone that only just discovered it. but i'm oh so glad i stopped in, to learn about trippy! it looks amazing.
So these types of routers are typically running at 100% CPU and - likely - not keeping up with packets that are not in the fast path? Ie the operators really only care about the packets in the fast path, all others can be ignored?
Or are there other types of packets in the slow path that do get a delivery guarantee by the router?
Why is it not on the fast path by now? Creating a single packet that doesn't need to be kept tracked of is a basic thing that shouldn't require that much ASIC space.
I worked on a board (a switch, not a router) with a chip that could saturate all 10 of its GigE ports all day long if you stayed in the fabric. But if you had to pass anything over to the built-in single-core 250 MHz CPU, you were in for a bad time. (Thankfully it also had pins for wiring up your own external CPU.)
I just ordered a dishwasher from Lowes, and that translated to 16 text messages from them, including asking if my address was correct, asking 3 times if the delivery date worked for me. I appreciated 2 of them: Your delivery window is 9:30-1:30, you are stop 7, the driver just finished the delivery before you and is headed your way.
There's a right number of times to text me about a delivery that is going exactly as planned, and 16 is not that number.
Hey Boris, thanks for this reply. I've been kind of scratching my head over this issue, assuming I'm just not doing "complex engineering", because since Opus 4.6 my seat-of-the-pants assessment is that it's a huge improvement. It's been like night and day in my use. Full disclosure: I use high effort for basically everything.
In fact, the only reference to crontab(5) is in the SEE ALSO section (on my version anyway), but that doesn't say why you might want to see crontab(5), just that it exists. That is spectacularly useless
Depends. If one is aware of the meaning of section numbers, that "(5)" is very obviously suggesting that there is a file format named "crontab" which is documented. It's also pretty reasonable to suppose that the command and the file format of the same name are related.
A novice might miss the convention and the connection. Man pages are not quite novice material.
Maybe they could update man files so that it lists crontab(file format) instead of crontab(5)? Whenever I've seen numbered man pages in the past, I thought it was just a page number in the manual for the program
Hell, you don't even have to have a handle on what the section numbers mean for these things to be useful. The appearance of something in a "SEE ALSO" section indicates that the manual page author thought that that thing was both related to the thing being documented and worth reading if the current man page didn't answer all of your questions.
I can't count the number of times that following the trail laid out by 'SEE ALSO' sections a step or three has lead me to the exact thing that I never knew I needed to be using. Chasing those sections down is almost always well worth the three to ten minutes spent.
And, like, if one is expecting a man page to cover in detail everything even vaguely related to what it documents, and one doesn't feel one has ten minutes to spend reading things that people thought were important to bring to your attention... well, I guess one could go ask an LLM to slop out some related words. That'll probably take less than ten minutes, though correctness is not at all guaranteed.
That is incredibly stupid. A documentation system designed by someone who doesn't understand how people use documentation.
If man was designed by someone with any taste at all it would at least give you a menu to select (1) crontab command, (5) crontab file format. Maybe we need a rewrite in Rust to fix that.
And since man pages could take minutes to print out, if you needed one you'd tear that section of paper off and keep it in a binder for future (and faster) reference.
Programs these old are controlled by people who are very strongly opposed to change, even if it improves things. They like living in the 80s.
I absolutely guarantee if you propose this change the the GNU neckbeards who control man they will come up with some bullshit technical reason why it can't be done.
Not that I know of, but I haven't looked. I have written a similar program for pulling arm64 instruction pages (which have many duplicates), the whole thing is under 100 lines, and most of that is printing and file IO that would be handled by the manpager, the actual finding dups and presenting a menu is even simpler.
And maybe we need some versions: man version 1, man version 2 and so on. And of course, in the style of GTK, each one incompatible with all the others. Progress. /s
Incidentally, man --help on my machine shows "-k, --apropos equivalent to apropos", which isn't very useful. I know the two are equivalent, because they're on the same line of switches, what does it actually do?
With some further man digging, apropos is actually a separate program that looks through man page names/descriptions for the argument. Unless you run it with no arguments, in which case it just outputs "apropos what?" Instead of an actual error message like "No search term provided" or something
> Incidentally, man --help on my machine shows "-k, --apropos equivalent to apropos", which isn't very useful.
That's your hint to execute either 'man apropos' or 'man man'. Both tell you in detail what the flag and utility do.
You seem likely to be very disappointed in the '-h'/'-H' output of utilities from the BSD tradition. The output is often a list of all of the (almost always exclusively short) options presented as a sea of characters... and nothing else.
I mean, most of the -h/--help texts I've read are generally pretty good. Obviously not a full documentation for the program, but they tell you what the switches do. I wish there was a consensus on whether to use -h or --help though
I assume you say that in jest, but back in the early '90s I was seriously considering getting a major in psychology and a minor in CS for the fairly hot Human Factors jobs.
Ditto, I made a "/codex-review" skill in Claude Code that reviews the last git commit and writes an analysis of it for Claude Code to then work. I've had very good luck with it.
One particularly striking example: I had CC do some work and then kicked off a "/codex-review" and while it was running went to test the changes. I found a deadlock but when I switched back to CC the Codex review had found the deadlock and Claude Code was already working on a fix.
https://github.com/linsomniac/ipq