[HN Gopher] Traceroute(8) Gets Speed Boost
___________________________________________________________________
Traceroute(8) Gets Speed Boost
Author : protomyth
Score : 54 points
Date : 2021-09-03 17:27 UTC (5 hours ago)
(HTM) web link (undeadly.org)
(TXT) w3m dump (undeadly.org)
| ur-whale wrote:
| How does that compare to tracepath?
| commandlinefan wrote:
| I hope this makes a difference - traceroute was invaluable when I
| first started working in networked environments, but over time,
| it's become effectively useless because it just reports "* * *"
| after the first couple of hops. I always assumed that was because
| of network security policies, but maybe it was just timing out
| the whole time.
| timw4mail wrote:
| What does the (8) mean?
| sulam wrote:
| Others have answered what the 8 means, you might also want to
| know why it's used, since it may be "obvious" that traceroute
| is a system utility. In many cases it's not obvious whether one
| is referring to the syscall, kernel API, system utility, etc,
| since overloading a single simple word is quite common.
| loeg wrote:
| Manual section 8 - "System Manager" commands.
| drran wrote:
| man 8 traceroute
|
| 8 is section number for this man page.
| [deleted]
| [deleted]
| drewg123 wrote:
| It references the BSD manual section where you can find the
| documentation.
|
| 1 General commands
|
| 2 Syscalls
|
| 3 Library functions
|
| 4 Kernel interfaces
|
| 5 File formats
|
| 6 Games
|
| 7 Misc
|
| 8 System commands
|
| 9 kernel dev
|
| [ EDIT: I have no idea how to make a single-spaced numbered
| list here.. ]
| Stratoscope wrote:
| > _I have no idea how to make a single-spaced numbered list
| here_
|
| Two spaces at the beginning of each line. This will also make
| the text monospaced, which you may not always want.
| sigjuice wrote:
| Quoting the manual section number is common practice in the
| OpenBSD project and community. It is used quite heavily in the
| documentation and on the mailing lists.
| p1mrx wrote:
| It's one of these mystery numbers: $ man
| printf [goddammit you stupid computer] $ man 3
| printf
| yardstick wrote:
| In linux you can already speed up traceroute with the -w argument
| to limit how long it waits for responses. Eg traceroute -w 2
| 8.8.8.8
| NelsonMinar wrote:
| It sounds like a good change but it's worth thinking about how
| this changes what traceroute actually does. I wonder if any
| significant amount of network infrastructure will respond
| differently to getting a bunch of probes with different TTLs all
| at once?
|
| (I've long since switched to MTR for most uses. It's different
| than traceroute in lots of ways and is noticeable.)
| SkipperCat wrote:
| I started to use MTR as my traceroute app and have never looked
| back.
| nullwarp wrote:
| thank you for this, i could have used this earlier debugging
| wireguard config. i have never heard of this tool before and
| it's phenomenal
| loeg wrote:
| (MTR is "my traceroute," for the unfamiliar.)
| donio wrote:
| I thought it was "Matt's Traceroute"
|
| edit, I guess not anymore
| kzrdude wrote:
| Why still using cvs? There must be some upside that they see
| sneak wrote:
| Tradition ("if it ain't broke...") as well as general
| resistance to things that may well be fads (eg github) are
| hallmarks of people who have been doing serous systems
| engineering for multiple decades.
|
| There are also real costs to switching tools, borne a little
| bit by everyone in the project. What they have is obviously
| working okay for them at the moment.
| fiddlerwoaroof wrote:
| Isn't OpenBSD reimplementing git so they could use it instead
| of CVS?
|
| http://gameoftrees.org/
| kzrdude wrote:
| Git now being a 16 year old technology, might be worth
| looking at for some.
| AceJohnny2 wrote:
| And before that, SVN was already considered a straight
| upgrade from CVS, and that's 21 years old.
| anjbe wrote:
| OpenBSD already officially mirrors the CVS repository to
| GitHub, and contributing patches via mailing list is
| substantially the same whether they're created with CVS or
| with Git. In other words, Git users already use Git to work
| on OpenBSD.
| upofadown wrote:
| One big cost would be changing all the documentation ...
| OpenBSD does that...
| tptacek wrote:
| _" No mention of openbsd on the internet is complete without a
| long thread about source control migration." -- tedu@_
| convolvatron wrote:
| why dont you just issue all the ttls concurrently?
| yannk wrote:
| You wouldn't know which packet reached its TTL just by flurry
| of ICMP packets received? i.e. what is the actual order of the
| path(s)
| sigjuice wrote:
| Shouldn't there be some way to match up an ICMP packet
| received to a particular probe(s) e.g. by UDP port or
| something else?
| [deleted]
| pphysch wrote:
| You don't know how many hops there are, so it would mean
| guessing beforehand, or using a big default (like 64) which
| means a ton of unnecessary packets for the average route.
| kwantam wrote:
| Possible solution: binary search to find the number of hops
| (buffering intermediate responses so that you don't have to
| re-send them), and send all missing TTLs in parallel once
| you've determined the number of hops to use.
|
| You could do a linear scan in parallel with the binary search
| so that the user-facing behavior looks more or less the same
| as now.
|
| (It could be that some utilities---including this one!!!---
| already do that. The linked article doesn't go into that
| level of detail and I haven't read the code.)
| athrowaway3z wrote:
| Knowing little about other use-cases, i would guess sending
| 1,2,4,8, ~12 is well within bandwidth budget for all people
| running traceroute.
|
| Some bastardized version of binary search sounds reasonable
| for most internet targets.
| Panino wrote:
| This is the kind of thing that keeps me running OpenBSD-current -
| super excited to see this in snaps! Awesome work!
| martin_ wrote:
| And here is the commit
| https://github.com/openbsd/src/commit/21b3e8786537fe05ba6f42...
___________________________________________________________________
(page generated 2021-09-03 23:02 UTC)