Stuart Henderson <[email protected]> wrote: > On 2021/09/01 11:25, Florian Obser wrote: > > So traceroute sends one probe, waits upto 5^W3 seconds for an answer to > > arrive, sends the next probe and so on. > > > > This makes it a bit faster (10x on a path with two intermediate systems > > not answering) by sending probes, waiting for the answer and doing > > reverse DNS lookups async. > > Basics are working here with icmp and udp. -A doesn't work reliably, > try it with an empty cache - I think it only prints if the route lookup > had a reply before the rdns lookup.
interesting, this will need to be found and fixed. > I don't know libevent, is it possible to reset the timer and skip the > 30ms delay if a response is received? Currently it's a little slower > for the case where all hops respond. that is an interesting idea also, it can be even faster. claudio/florian and i have talked a lot about trying to send back-to-back packets to a single ttl target, because it may trigger control plane protection filters in those intermediate hops. but increasing the pace to other targets, is fine. > Hosts that don't respond result in a lot of *'s printed quickly, maybe > scrolling the useful output off the terminal. The overall output is the > same as the sequential version if you actually leave it to finish but > most users would have hit ^C by then. I don't know what could be done > to improve it (suppressing multiple * * * lines might help?) but user > experience with that isn't great as-is. Try mp3.com for an example. there are two proposals for this, which would diverge the output: 15 * * * [repeating to ttl 64] or 15 * * * [repeating to ttl 64] how often do people run scripts against traceroute output, which will care about this change in format. I also considered a third option -- to meter the * * * printout lines rate to 3/second, but this kind of conflicts with the goal for speeding things up.
