Feature Requests + Changes, to match mtr

[MrHamel]

My mtr alias is mtr -bezo LDRSNBAWVGJMXI, which you'll see a ton more columns for the ping stats (-o column letters), among other information.

-> # ttl --version
ttl 0.13.2

I would like to see...

• Control of the stat column arrangement / what is enabled or disabled by arguments (-o parity)
• More column stats to be on par with mtr (Run it with mtr -bezo LDRSNBAWVGJMXI and you see what you're missing immediately)
• All of the columns updating at the same rate when packets are sent/received, not after x amount of packets or time
• When displaying the hop information, that data must also update at the same rate, not after x amount of packets or time
• Display the (full exact) hostname and IP address concurrently (mtr -b)
• AS lookup also includes the ASN (mtr -z)
• AS lookup includes full name on the wide display

[MrHamel]

Reading this issue back this morning, I realized it's a lot of requests to have in a single ticket here, and apologize for making this ticket a dumping ground of sorts.

I can break this down into smaller tickets if you'd like, in the meantime I have converted it into a set of checkboxes.

[lance0]

No worries. This is fine !

[lance0]

Some progress on these:

• "All columns updating at the same rate" - TUI now runs at 60fps as of v0.15.0, so updates should feel immediate
• Column control and additional stats are tracked on the roadmap under TUI Polish

Keeping this open as a tracking issue. These are good targets for a future release.

[MrHamel]

The only thing immediate is the number of packets sent. The rest of the columns and the hop dialog still lag behind in updates.

[lance0]

Should hopefully have an overhaul coming soon. I'm finalizing the changes based on your feedback. Thanks a ton!

[lance0]

The stat column desync is fixed in v0.15.1 — the Sent counter now updates atomically with Avg/Min/Max/Loss instead of racing ahead. All columns update together when a probe is resolved (response or timeout).

[jimsiff2]

I hope this comment adds a little context to the request "AS lookup also includes the ASN (mtr -z)".

With the ASN feature, I view the actual ASN as the key datapoint and the description as a nice to have. If the actual ASN is placed ahead of the ASN description in the ttl ASN field, then we will always see the actual ASN and a cropped ASN description regardless of our display width setting. On 0.15.2, I see the ASN before the description like I described above if I navigate to the hop details screen:

ASN: AS209 (CENTURYLINK-US-LEGACY-QWEST - CenturyLink Communications,

However, on the main ttl screen, I see the following for the same hop on the wide display view:

CENTURYLINK-US-LEGACY-QWEST …

Thanks for your continued work on this project @lance0.

[MrHamel]

While the columns all update at once, tt still feels like it updates one a second. When I run this ttl --interval 0.1 --pmtud --rate 0 --resolve-all --wide mindat.org, I expect the columns to update 10 times per second, based on the --interval parameter. I suggest playing around with mtr to understand what I'm looking for.

I am not sure if it's related to this (I wrote out a separate issue), where the sender probe count for each hop in the trace are all desynced from each other.

[lance0]

@MrHamel Thanks for the follow-up. The stat columns updating together was the fix in v0.15.1 — that's working as intended now.

On the refresh rate question: the TUI actually refreshes at ~60fps (every 16ms), but you're right that it doesn't feel that fast. Here's why:

With --interval 0.1, probes are sent every 100ms. But each probe still needs to:

1. Travel to each hop
2. Wait for ICMP response (or timeout after 3 seconds)
3. Be processed by the receiver

So the display updates 60 times per second, but there's only new data to show when probe responses arrive. With 30 hops and --interval 0.1, responses trickle in over ~10-200ms depending on network latency, and the next round starts at t=100ms.

The architecture intentionally batches display updates rather than updating each hop independently as responses arrive. This keeps all hops visually synchronized (no "rolling" updates) and avoids lock contention that caused the freezing you reported in #19.

On the per-hop sent count desync — I saw you filed a separate issue. That's likely related to how different hops have different response times. Closer hops resolve faster, so their sent counts tick up sooner than distant hops still waiting for responses/timeouts. This is expected behavior with the deferred counting approach.

If you're looking for mtr-like behavior where each hop updates independently as responses arrive, that would require a different architectural approach with some tradeoffs. I'm open to exploring that direction if it's something you'd find valuable — happy to discuss further.

[lance0]

The ASN column now shows AS##### name format in v0.15.3, so the ASN number is always visible even when truncated.

[MrHamel]

Well, you are preaching this as an alternative to mtr, so I'm expecting the data and refresh rate to be on par with it. The sent probe counter should always increment when it's sent on that interval, meaning no lag. You'll also notice in mtr that the stats will always update on that interval, and consider the probe as a timeout/no response for that hop, until it responds back which then backfills and recalculates the stats. What I mean is, the "frame rate" / "refresh rate" is set by the interval, not a hard coded constant.