cancel
Showing results for 
Search instead for 
Did you mean: 

Workstations down (disconnection)

Former Member
0 Kudos

My work stations, leaving the system with the following message to the whole time:

My workstations down Thu Mar 13 20:17:38 2008

Network error of client T31, NiBufReceive (-6: NIECONN_BROKEN), dp_tm_status=3

Client address of T31 is 128.1.0.19(camioss)

***LOG Q04=> DpRTmPrep, NiBufReceive (62 JOSILENE 31 CAN-BALA-CAG)

RM-T31, U62, 400 JOSILENE, CAN-BALA-CAG-03, 20:17:38, M0, W0, ZARM, 2/1

      • ERROR => DpRqCheck: T31 in state TM_SLOT_FREE

***LOG Q0G=> DpRqBadHandle, bad_req ( DIA)

      • ERROR => BAD REQUEST - Reason: DpRqCheck failed (line 6054):

-IN-- sender_id DISPATCHER tid 31 wp_ca_blk -1 wp_id -1

-IN-- action SEND_TO_WP uid 62 appc_ca_blk -1 type DIA

-IN-- new_stat NO_CHANGE mode 0 len -1 rq_id 2558

-IN-- req_info LOGOFF CANCELMODE

Thu Mar 13 20:27:59 2008

***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer)

      • ERROR => NiIRead: SiRecv failed for hdl 9 / sock 160

(SI_ECONN_BROKEN/10054; I4; ST; 172.22.25.9:1660)

Network error of client T37, NiBufReceive (-6: NIECONN_BROKEN), dp_tm_status=3

Client address of T37 is 172.22.25.9(JAT-BAL-CAGL-04)

***LOG Q04=> DpRTmPrep, NiBufReceive (72 NADIA 37 JAT-BAL-CAGL)

RM-T37, U72, 400 NADIA, JAT-BAL-CAGL-04, 20:27:40, M0, W0, ZARM, 3/1

Thu Mar 13 20:29:05 2008

***LOG Q0I=> NiIRead: recv (10054: WSAECONNRESET: Connection reset by peer)

      • ERROR => NiIRead: SiRecv failed for hdl 9 / sock 160

(SI_ECONN_BROKEN/10054; I4; ST; 172.22.25.9:1663)

Network error of client T37, NiBufReceive (-6: NIECONN_BROKEN), dp_tm_status=3

Client address of T37 is 172.22.25.9(JAT-BAL-CAGL-04)

***LOG Q04=> DpRTmPrep, NiBufReceive (74 NADIA 37 JAT-BAL-CAGL)

RM-T37, U74, 400 NADIA, JAT-BAL-CAGL-04, 20:28:46, M0, W0, ZARM, 3/1

Thank´s

Pamplona

Accepted Solutions (0)

Answers (6)

Answers (6)

Former Member
0 Kudos

Had the same issue and found that the new servers that have processors on the network cards result in network packet loss with SAP applications. Switch off option on network card to process network via CPU and no the network card processor.

NIPING is a great tool to find the problem! It is a SAP tool that tests the Network Interface Layer (NI) of a SAP a client to a SAP Server (you load it both ends) Download from SAP Market Place. You need the newest NIPING version for this test, please follow SAP note 799428 to get it.

Took this from another site: Option 2 reported network packet loss. Network guys were then able to trace the issue to network card settings.

NIPING Documentation – 13 May 2008

Network connection interrupted or poor network performance.

Other terms

Network, SAP GUI, SAPGUI, RFC, ITS, bandwidth, throughput, latency, round trip time, RTT

Solution

To help diagnose the network or measure network metrics you can test the connection using SAP's NIPING program. You can use NIPING to analyze the network connection between any two machines running SAP software, for example between:

Frontend PC and application server

Two application servers, perhaps belonging to different SAP systems

Application server and database server or live cache server

RFC server or client programs and application server

The machines can be connected either by a local area network (LAN) or wide area network (WAN).

In contrast to the normal PING command, NIPING operates on the TCP socket layer, which is the same layer used by SAP application programs. Therefore, NIPING can be used to identify also errors related to the TCP and socket implementation on the platform.

Please fetch the latest version of NIPING from the service market place as described in SAP note 799428. If this is not possible for you, you can use the NIPING which is located in the executables directory on any SAP server.

How to use NIPING

Starting NIPING without arguments displays a short help message. Find a short exlanation of the most important options below:

First start the NIPING server on computer A (e.g., the Application Server) with the command line:

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

Then start the client (e.g. on the front-end machine) with the command:

niping -c -H [ -B -L -D ]

may also be the host name or the IP address of host A. The remaining arguments are optional.

(default 1000 bytes) determines the size of the data packets. Please test at least the values 500, 1000, 1400, 1500, 4000 and 10000. This test is especially important to find errors related to the maximum transmission unit (MTU). Please also refer to notes 26086, 107407, 67098 and 44803.

is the number of packets sent (default 10). To find spurious erors it may help to simulate high network load using 1000 loops or more. For a permanent test use a number of e.g. 1000000 loops.

If you test during productive hours and don't want to consume too much bandwidth you can set a between requests ( is in milliseconds).

Examples

1) Measuring network metrics (throughput and RTT)

Throughput is the number of bytes per second that an application can send through the network. Measured values will vary according to the actual load of the network. Round trip time (RTT) is the time for a small data packet to be transmitted from the sender to the receiver and back again to the sender. RTT is mainly influenced by network topology and equipment and normally cannot be improved significantly by increasing bandwidth.

Measuring throughput

niping -c -H -B 100000

The use of large blocks reduces impact of network latency. After completion niping will report throughput as value tr2 in kB/s (kilobytes per second).

Measuring RTT

niping -c -H -B 1 -L 100

(The buffersize of 1 may cause an error in older versions of niping. If so please use niping -c -H -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)

2) Long LAN stability test:

niping -c -H -B 10000 -D 100 -L 360000

This test will consume 100000 Bytes/second of bandwidth (about 10% of a 10 mbps Ethernet) and run for 10 hours.

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

3a) Long WAN test (stability):

niping -c -H -B 200 -D 1000 -L 36000

This test uses about 5% of an ISDN line of 64 kbps and also runs for 10 hours.

Interpreting NIPING's output: In this test, the times measured by NIPING correspond mostly to the network latency (round trip time - RTT). The throughput measurement has no meaning in this case.

3b) Long WAN test (idle timeouts):

niping -c -H -P -D 3600000

This test establishes a TCP connection and sends a test packet every

hour (delay of 3600000ms). It runs for 10 hours. The goal is to see if

the TCP connection is disrupted by some "idle timeout". Most firewalls

apply such timeouts. But SAP applications make use of long lasting TCP

connection and thus may be hit by such idle timeouts.

You need the newest NIPING version for this test, please follow SAP

note 799428 to get it.

4) Short throughput/stability test:

niping -c -H -B 1000000 -L 100

Tests connection with 100 MB of data as fast as possibly. On a 100 Mbps Ethernet this should take about 10 seconds. During the test, other applications may be impaired. On a slow WAN connection, reduce loops to 10 (-L 10).

Interpreting NIPING's output: This test uses large blocks of data. Therefore, it can be used to measure throughput available to NIPING. Check the output "tr2". It states the throughtput in kilo-byte per second measured from all packets except the fastest and the slowest one. Multiply this value by 10 to obtain an estimate of the line bandwidth in kilo-bit per second (kbps). Does this value differ by a large amount (at least a factor of two) from the one expected for the connection you are analyzing? This could be an indication of network problems: Either the line is overloaded, or there are other problems with the connection.

5) MTU test:

See related notes 155147 and 107407 for an explanation of this test (even if you are not analyzing a Windows system).

niping -c -H -B

Vary X according to the values given above (500, 1000, 1400, 1500, 4000, 10000 and 40000)

Note for Windows NT/2000: If client or server are under heavy load while you perform the measurement, you should start NIPING with high priority. To do this, start NIPING with the following command line:

start /b /wait /high niping

Please test the TCP/IP communication between all concerned machines. Using the options described above, you can either do a long time connection test to find intermittent problems or do a short term stress test with large packets to find fundamental connection problems.

NIPING should not abort with an error message under any circumstances. If you can reproduce an error using NIPING then the problem is definitely related to the network layers, not to 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

Replace with an appropriate file name for trace output.

Now send both trace files along with a description of what you did to produce the traces to SAP. (For example, attach the files to a problem message).

Former Member
0 Kudos

What version for SAP are you running?

Former Member
0 Kudos

Hi,

This is interesting. We have just created a "play pen" for ECC6. When we go via a VPN connection using GUI 7.10 patch 7 - the old SAP R/3 production system and development system do not time out and stay active.

However when we log onto the ECC6 "play pen" the system times out after a few minutes and gives the error message:

10054: WSAECONNRESET: Connection reset by peer) [nixxi.cpp 4854]

I suspect it is not a network issue but a GUI 7.10 issue with ECC6. I can have 3 sessions open via the VPN:

1) SAP 4.6C production

2) SAP 4.6C development

3) SAP ECC6 development

1 and 2 stay up but session 3 times out! It therefore cannot be the VPN or the network.

What version of SAP are you having this issue with?

We have written a ABAP that polls the server and stops the timeout - but this is not the long term solution... There is an issue when SAP is idle with a high latency on the network. We do not have this issue if we are on the LAN or WAN, but our VPN users are dropped.

Edited by: ed montocchio on May 7, 2008 8:14 PM

Former Member
0 Kudos

Hello Joey

I already set the sapgui slow connection, unicode off and

Message Server Timeout in Seconds 100

Thanks

Pamplona

Former Member
0 Kudos

Do you have SAPGUI installed on the message server itself?

Logging on at the message server removes the network from the equation, so that should tell you if it is a problem with the message server.

I suspect it is a network issue. Perhaps your network team can run a sniff test on the line.

Former Member
0 Kudos

I have the similar problem. We have a very good network so I do not see this as the problem. Most affected users are in location with high latence.

The reason I am saying it is not a networ problem is that the users that are disconnected log in via the logon group to application servers (we are not allowing people to log in to the central instance). When we take the most hit users and put them on the central instance they work happily without any disconnections.

Can you think of any registry, parameter values that can be responsible for this.

Our Central instance is a powerful Itanium box running Windows +MSSQL

App servers are AMD boxes

Any help would be gratly appreciated

Former Member
0 Kudos

Juan,

I am using sapgui 7.10 in the last patch 6.

I believe that has something wrong with the application because in some attempts to logon returns "waiting for response" to fall by a timeout.

Thank´s

Pamplona

Former Member
0 Kudos

It is likely a network issue.

Sometimes this can be alleviated by setting the item inside SAPLogon to "Low Speed Connection" under the "Connection Speed" box inside Change Item -> Advanced.

JPReyes
Active Contributor
0 Kudos

That looks like either SAPGui of Network issues.

Please update your gui to the latest patch level and try it again.

regards

Juan