point to point throughput using two sizes of ICMP ECHO_REQUEST packets to
pairs of remote hosts.
determines bandwidth on a point-to-point link
by sending ICMP ECHO_REQUEST packets and measuring their roundtrip times for
different packet sizes on each end of the link.
is supposed to be the nearest end of the
link, while host2
is the other end.
The options are as follows:
- Stop after count resets of
the stats. Useful only in conjunction with the
-e option. Defaults to 1.
- Set the
on the socket being used.
- Display the measured throughput at every received packet.
By default, it is displayed only when the computed value changes, which
itself changes only when the minimum roundtrip time for one of the packet
- Reset stats after sending
samples ECHO_REQUEST packets.
- Saves the bandwidth measurements to the file
- Wait wait seconds
for each ECHO_REPLY packet. The default is to
wait for four seconds.
- Numeric output only. No attempt will be made to lookup
symbolic names for host addresses.
- Be pedantic regarding round-trip times.
Normally, bing assumes that the roundtrip time
for a small packet should always be smaller than the roundtrip time for a
big packet to the same host, that for a given size the roundtrip time for
host1 should always be smaller than the
roundtrip time for host2, and that the
increase in the roundtrip time between host1
and host2 should always be bigger for big
packets than for small packets.
Bing takes advantage of this to better
determine the minimum roundtrip times.
Option -P disables this behaviour, in the
unlikely event it could be of any use someday. Even IP/X25 links are not
weird enough to require this, though.
- You may specify up to 16 ``pad'' bytes to fill out the
packet you send. This is useful for diagnosing data-dependent problems in
a network. For example, “
-p ff” will
cause the sent packet to be filled with all ones.
- Record route. Includes the RECORD_ROUTE option in the
ECHO_REQUEST packet and displays the route buffer on returned packets.
Note that the IP header is only large enough for nine such routes. Many
hosts ignore or discard this option.
- Bypass the normal routing tables and send directly to a
host on an attached network. If the host is not on a directly-attached
network, an error is returned. This option can be used to ping a local
host through an interface that has no route through it (e.g., after the
interface was dropped by routed(8) ).
- Specifies the number of data bytes to be sent in the small
packets. The default and minimum value is 8.
- Specifies the number of data bytes to be sent in the big
packets. The default is 108. The size should be chosen so that big packet
roundtrip times are long enough to be accurately measured (depending on
clock resolution and number of hops).
- Specifies that bing should
start sending packets of the size of small
packetsize and then increase the size by
size increment until it reaches
- Verbose output. ICMP packets other than ECHO_RESPONSE that
are received are listed.
- Very verbose output. The roundtrip time of each received
echo is displayed.
- Display possible warnings about roundtrip times all the
time. By default, warnings are printed only at the end.
- Fill packets with uncompressible (pseudo-random) data.
Round-trip times and packet loss statistics are computed. If duplicate packets
are received, they are not included in the packet loss calculation, although
the round trip time of these packets is used in calculating the
minimum/average/maximum round-trip time numbers. When the specified number of
loops have been made or if the program is terminated with a
, a brief summary is displayed.
This program is intended for use in network testing, measurement and management.
Because of the load it can impose on the network, it is unwise to use
during normal operations or from automated
Many Hosts and Gateways ignore the RECORD_ROUTE option.
The maximum IP header length is too small for options like RECORD_ROUTE to be
completely useful. There's not much that that can be done about this, however.
Some of the final stats (average throughputs) almost never give a even
marginally correct result.
Pierre Beyssac <firstname.lastname@example.org>