Skip to content
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

Why is the return time longer than the native PING? #20

Open
blackboar opened this issue Jun 10, 2022 · 1 comment
Open

Why is the return time longer than the native PING? #20

blackboar opened this issue Jun 10, 2022 · 1 comment

Comments

@blackboar
Copy link

Why is the return time longer than the native PING?
About 2-3ms, is there any solution?

@scottlaird
Copy link

I keep asking myself the same question. Using ping_exporter (which is basically just a wrapper around go-ping, pinging between two systems on my network, I see ~230 µs for IPv6 and ~210 µs for IPv4.

Running ping on the command line between the same systems gives a mean latency of 65 µs for IPv4 and 68 µs for IPv6.

At least part of this is ping using SIOCGSTAMP by default; this reports the kernel's packet receive time instead of calling gettimeofday during the packet processing process. You can disable this with ping via -U; on my system this adds an extra 70 µs or so to the RTT displayed. Since that's using fairly simple C, I could absolutely see calculating timestamps in Go adding an extra 100 µs.

There are two ways to get this data from the kernel; either SIOCGSTAMP (via ioctl) or SO_TIMESTAMP (via recvmsg). It looks like they're both possible in Go, but neither is terribly portable or clean. See go-pinger's source for SIOCGSTAMP and pcapgo's source for SO_TIMESTAMP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants