SAP Note 500235 - Network Diagnosis with NIPING

SAP Network Diagnosis with NIPING

Issues

Interrupted network connections or poor network performance are both possible outcomes.
Other terms
RFC, ITS, bandwidth, throughput, latency, round trip time, RTT, SAP GUI, SAPGUI

Solution & Recommendation
You can use SAP's NIPING application to test the connection to assist diagnose the network or evaluate network parameters. NIPING can be used to examine the network connection between any two SAP-enabled devices, for example, between two SAP-enabled machines.:

Application server and frontend PC

Two application servers, maybe from separate SAP systems

Application and database servers, as well as a live cache server

Client programmes, RFC server, and application server

A local area network (LAN) or a wide area network (WAN) can connect the machines (WAN).

NIPING, unlike the standard PING command, uses the TCP socket layer, which is the same layer that SAP application applications use. As a result, NIPING can be used to detect issues relating to the platform's TCP and socket implementation.

As mentioned in SAP note 799428, please obtain the most recent version of NIPING from the service market place. If this is not possible, you can utilise the NIPING programme, which can be found in any SAP server's executables directory.

How to use NIPING

When you run NIPING without any arguments, it displays a little help message. Below is a quick rundown of the most important options:

Start the NIPING server on computer A (for example, the Application Server) by entering the following command:

  niping -s -I 0        (the last character is zero, not the letter O)

Then run the following command to start the client (for example, on the front-end machine):
  niping -c -H <nipingsvr> [ -B <buffersize> -L <loops> -D <delay> ]

         The host name or IP address of host A might alternatively be nipingsvr. The rest of the arguments are purely optional.

The size of the data packets is determined by buffersize> (default 1000 bytes). Please test the figures 500, 1000, 1400, 1500, 4000, and 10000 at the very least. This test is particularly helpful for detecting problems in the maximum transmission unit (MTU). Notes 26086, 107407, 67098, and 44803 should also be considered.

            The number of packets transmitted is referred to as loops> (default 10). Simulating heavy network load with 1000 loops or more may aid in the detection of bogus errors. Use a large number of loops, such as 1000000, to create a persistent test.

You can define a delay> between queries (in milliseconds) if you're testing during business hours and don't want to waste too much bandwidth.

Samples of 

Measuring network metrics (throughput and RTT)

The throughput of a network is the number of bytes per second that an application can transfer. The measured values will change depending on the network's real load. The time it takes for a tiny data packet to travel from the sender to the receiver and back to the sender is known as round trip time (RTT). RTT is mostly impacted by network structure and equipment, and it is usually not greatly improved by adding bandwidth.

Measuring throughput
niping -c -H <nipingsvr> -B 100000

On a gigabit network, we suggest to use the biggest possible block size
which is 8000000.

The utilisation of huge blocks decreases network latency's influence. niping will report throughput as tr2 in kB/s after finishing (kilobytes per second).

In general, you may not be able to obtain a network's true maximum throughput. On the other hand, because NIPING uses the same NI library for network communication, you can expect "realistic" results for SAP products.

Typical throughput values:

Gigabit Ethernet - 100000 KB/s
Fast Ethernet - 10000 KB/s
WLAN (IEEE 802.11g) - 5000 KB/s
DSL 1000 - 100 KB/s
ISDN - 7 KB/s
UMTS - up to 700 KB/s
GPRS - 6 KB/s

Measuring RTT

niping -c -H <nipingsvr> -B 1 -L 100
(The buffersize of 1 may cause an error in older versions of niping. If so please use  niping -c -H <nipingsvr> -B 20 -L 100   instead)
Small blocks and 100 loops are used to measure the average RTT. The value av2 represents the RTT in ms (milliseconds)

Typical RTT values:

Fast Ethernet - <1 ms
WLAN (IEEE 802.11g) - 10 ms
Cable - 10 ms
DSL without Fastpath - 40 ms
ISDN - 200 ms
UMTS - 300 up to 400 ms
GPRS - 700 up to 1000 ms
Satellite - 1000ms

Long LAN stability test:

niping -c -H <nipingsvr> -B 10000 -D 100 -L 360000

This test will use 100000 bytes per second of bandwidth (about 10% of a 10 mbps Ethernet) and will last 10 hours.

This test requires the most recent NIPING version; to obtain it, see SAP note 799428.

Long WAN test (stability):

niping -c -H <nipingsvr> -B 200 -D 1000 -L 36000

This test consumes around 5% of a 64-kbps ISDN connection and lasts for 10 hours.

NIPING's output should be interpreted as follows: The times measured by NIPING in this test primarily correspond to network delay (round trip time - RTT). In this instance, the throughput measurement is meaningless.

Long WAN test (idle timeouts):

niping -c -H <nipingsvr> -P -D 3600000

Every hour, this test starts a TCP connection and delivers a test packet (delay of 3600000ms). It lasts for ten hours. The purpose is to see if a "idle timeout" interrupts the TCP connection. These timeouts are used by most firewalls. SAP programmes, on the other hand, rely on long-lasting TCP connections and may be affected by idle timeouts.

You need the newest NIPING version for this test, please follow SAP
note 799428 to get it.

Short throughput/stability test:

niping -c -H <nipingsvr> -B 1000000 -L 100

Connection is tested with 100 MB of data as quickly as possible. This should take roughly 10 seconds on a 100 Mbps Ethernet connection. Other applications may be hampered during the test. Reduce loops to 10 on a sluggish WAN connection (-L 10).

The output of NIPING should be interpreted as follows: This test uses big chunks of data. As a result, it can be used to determine the amount of throughput accessible to NIPING. Look at the "tr2" output. It specifies the total throughput in kilobytes per second, excluding the quickest and slowest packets. To get an estimate of the line bandwidth in kilobits per second, multiply this amount by ten (kbps). Is there a significant difference between this value and the one expected for the link you're looking at (at least a factor of two)? This could be a sign of network issues: either the line is overloaded, or the connection is having other issues.

MTU test:

For further information on this test, see related notes 155147 and 107407. (even if you are not analysing a Windows system).

niping -c -H <nipingsvr> -B <nnn>

Vary <nnn> according to these values: 500, 1000, 1400, 1500, 4000, 10000 and 40000

Additional information

Note for Windows NT/2000: If the client or server is under a lot of pressure when you're measuring, you should start NIPING as soon as possible. To accomplish so, enter the following command into NIPING:

start /b /wait /high niping <normal_NIPING_arguments>

Please verify that all machines involved are communicating over TCP/IP. You can either run a long-term connection test to detect intermittent difficulties or a short-term stress test with huge packets to find basic connection problems using the tools indicated above.

NIPING should not abort with an error message under any circumstances. An error is always indicated by a line starting with "*** ERROR ...".
Entries like "NiIRead: hdl 0 recv would block (errno=EAGAIN)" do not indicate an error!

If you can duplicate an error with NIPING, the issue is almost always with the network layers rather than the application.

Information needed by SAP

If you need further assistance from SAP support, please start both client and server with the additional argument
-V 2 -T <tracefile>

For trace output, replace tracefile> with an appropriate file name. Send both trace files to SAP, together with an explanation of how you created the traces. (Attach the files to a problem message, for example.