Fast pinging without requiring the response

Question

I am trying to measure one way latency between two machines and I would like to use ping to send ICMP packets from one machine to another. The interval between the packets should be 1 micro second (1us) and I want to sent 1 million packets (10^6), so it should take 1 second in total to send the packets.

Also, I do not care about the response of the other machine (I will only capture the packets on the second machine and analyze them).

Right now I have tried:

ping -I eth0 -c 1000000 -l 1000000 -f -i 0.000001 -b 255.255.255.255

I also experimented by deactivating the -l and the -f options. When I use a large value for the -l I get a warning that the rcvbuf is not enough to hold preload.

I am using tcpdump to capture the outgoing packets from my machine and also to incoming packets to the other machine.

The issue is that the interval between the packets is between 5us and 15us in most cases, and slightly larger.

I have the same issue when I am sending directly to a website like google:

ping -I eth0 -c 1000000 -l 1000000 -f -i 0.000001 google.com

---

What I want is to:

• send packets from one machine to another
• without the first machine to wait for any response
• and the interval between the packets to be 1us

It will be preferable to do it with the ping command and the options that it provides (if they are sufficient). I have administrator privileges.

---

Update

My goal is to measure latency that different cables introduce on the packets. So I need accurate packet generation and capture. In terms of hardware I have the appropriate tools, but I do not get what I expect. I believe that the problem is with the software.

The issue for me is that ping does not seem to work as expected when I am using the -i option. When I am using -f -l 1000000 the captures are send every 3us to 5us. When I specify -f or none of these two, the packets are generated every 12ms.

Generally, I think that I cannot control the packet distance of a broadcasted ping.

Solution 1

ping -f will not wait for the remote party to reply.

However, a 1us delay between consecutive packets can simply be too much to ask from your hardware (CPU) and software (IP stack) combination.

To maximize performance (and minimize sending delay) try disabling any power management function or, at very least, use the performance CPU governor.

Solution 2

Probably you make a confusion between latency and throughput. It's enough to send 1 packet and measure its delay to determine the latency. All you need is a mechanism to measure the time with high accuracy. One way is PTP (Precision Time Protocol) - i.e. the sender attaches a timestamp to the sent packet. WRT throughput, the size of the packets is crucial - by default pings would be 64 bytes long.