-
-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Traceroute do not resolve #599
Comments
Sure I think we can do it. But can you please tell us more about the use-case? To better understand what the end goal is and help us set priorities. |
just to provide a quicker output. it takes slightly longer when ip addresses have to be resolved to hostname's From traceroute man page: |
Indeed the difference in speed is significant. We should do it, just need to make sure we handle correctly the new output format |
The difference is negligible in most cases. It'll likely take you more time to write the two extra characters or click the switch than it would save on the execution time. I'd rather not add new options without serious consideration, as each tool we support has tens of them. |
On a large scale if someone asks for hundreds of traceroutes it would make a lot of difference |
It doesn't matter how many you run if the difference is < 100 ms on a measurement that takes 5 - 10 seconds. Traceroute is usually slow because of waiting for the tracing packets, not because of DNS. |
For me the difference was closer to 3-4 seconds |
@MartinKolarik Respectfully, you should let the users decide if that's a negligible difference or not. Giving us another way to fine-tune our tests would make it easier to tweak things to fit our needs without imposing a one size fits all approach |
Can we get a -n flag for traceroute that prints the server's with just ip addresses and also to avoid a name server lookup?
The text was updated successfully, but these errors were encountered: