5

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.

Grey
  • 151
  • 1
  • 4
  • 2
    with these requirements, it wouldn't surprise me if ping is inadequate, maybe do it yourself in your favorite non-interpreted fast programming language (C would suffice) – hanshenrik Sep 02 '17 at 22:21
  • 4
    Saturating gigabit ethernet (without using jumbo frames) requires about 83 000 packets/sec (of 1500 bytes each). You're looking to send a million packets/sec. Considering every packet has some overhead associated with it at the software level (and possibly the network interface hardware level, too), sending 12 times the normal maximum packets/sec might not be feasible. – marcelm Sep 02 '17 at 23:25
  • 1
    @marcelm: But are they 1500 bytes each? – user541686 Sep 03 '17 at 00:11
  • Maybe there is a hidden request/issue behind this question? – Paolo Sep 03 '17 at 05:50
  • 1
    @Mehrdad 1500 bytes (1522 actually, but who's counting) is the maximum Ethernet frame size. Ping packets (ICMP echo request) don't need that maximum size and typically don't use it. In fact, ICMP echo requests are smaller than the _minimum_ Ethernet frame size of 64 bytes and thus need padding to even be transmittable. At the minimum frame size a theoretical 1.7 million packets/sec is possible. But things are likely not optimized for that, as high-bandwidth traffic tends to use the largest possible packet size for efficiency. – marcelm Sep 03 '17 at 11:04
  • @marcelm: Right but then that's what you should mention. You make it sound completely ridiculous to expect 1M packets/sec the way you cite the 83K figure, whereas with a peak limit of 1.7M it's actually rather reasonable. – user541686 Sep 03 '17 at 11:54
  • 2
    @Mehrdad No, I shouldn't. The normal expected maximum for GigE is 83kpkts/sec. Expecting 1Mpkts/sec, or 12 times the "normal" maximum, is pushing things and _may_ not be possible with the OP's hardware/software combination. That was my original point and it still stands. The fact that in theory GigE could do 1.7Mpkts/sec doesn't mean the practical hardware and software can actually do that, as flooding GigE with the smallest possible packets is not expected operation. – marcelm Sep 03 '17 at 13:37
  • @marcelm 1500/1522 isn't the maximum Ethernet frame size, at least not in reality. Most gigabit hardware supports jumbo frames, up to at least 9000 payload bytes. (And of course, 10gig and 40gig Ethernet are around, too) – derobert Sep 05 '17 at 19:59
  • Maybe take a look at https://www.kernel.org/doc/Documentation/networking/pktgen.txt or similar for whatever OS you're running on? – derobert Sep 05 '17 at 20:00

2 Answers2

11

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.

shodanshok
  • 44,038
  • 6
  • 98
  • 162
4

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.

marian adam
  • 41
  • 1