Interpreting tcpInOutofOrder% in Netmaster Performance Display
search cancel

Interpreting tcpInOutofOrder% in Netmaster Performance Display

book

Article ID: 259911

calendar_today

Updated On:

Products

NetMaster Network Management for TCP/IP

Issue/Introduction

See the below screen from The Performance Overview (/PERF) screen.   I'm concerned about the items in red, that's a really high pecentage.
Does that represent all connections across the stack or just the highest single connection or goup of connections ? 

NMASTR------------------------------------------- TCP/IP : Hourly Summary List ------------------------------------
Command ===>                                                                           
                                                                                                                  
     Resource ID ......... Stack TCPIP11                                                                         
     Attribute ID (Type)   tcpInOutofOrder% (gauge)                                                               
     Description ......... TCP segments rcvd out of order as % of rcvd                                           
     Period .............. Last 1620 hours, since Sat 10-DEC-2022                                                  

     Summary         Start    Hourly    Hourly    Hourly HourOfDay HourOfDay DayOfWeek DayOfWeek     Daily   Daily
     Date            Hour    Average       Min       Max  Baseline    % Diff  Baseline    % Diff  Baseline  % Diff
     Fri 10-Feb-2023 16:00      0.4         -         -       0.3       +30%      1.1       -67%      1.1     -67%
     Fri 10-Feb-2023 15:00      0.3         -         -       0.5       -28%      1.1       -69%      1.1     -69%
     Fri 10-Feb-2023 14:00     11.2         -         -       1.3      +746%      1.1      +954%      1.1    +964%
     Fri 10-Feb-2023 13:00     28.5         -         -       3.1      +835%      1.1    +2,591%      1.1  +2,616%
     Fri 10-Feb-2023 12:00     25.8         -         -       2.9      +785%      1.1    +2,330%      1.1  +2,361%
     Fri 10-Feb-2023 11:00      0.2         -         -       0.2        -5%      1.1       -82%      1.1     -82%
     Fri 10-Feb-2023 10:00      0.4         -         -     < 0.5       -22%      1.1       -67%      1.1      67%
     Fri 10-Feb-2023 09:00      0.3         -         -       0.3       -10%      1.1       -75%      1.1     -74%
     Fri 10-Feb-2023 08:00      1.3         -         -       0.6      +110%      1.1       +19%      1.1     +20%
     Fri 10-Feb-2023 07:00      0.3         -         -     < 0.5       -44%      1.1       -75%      1.1     -74%
     Fri 10-Feb-2023 06:00      0.3         -         -     < 0.3        +4%      1.1       -75%      1.1      75%
     Fri 10-Feb-2023 04:00      0.2         -         -     < 0.3       -28%      1.1       -78%      1.1     -78%
     Fri 10-Feb-2023 03:00      0.2         -         -     < 0.4       -50%      1.1       -79%      1.1     -79%
     Fri 10-Feb-2023 02:00      5.5         -         -     < 1.2      +371%      1.1      +415%      1.1    +420%

 

 

Environment

Netmaster for TCP/IP Release : 12.2

Resolution

This display represents all connections across the stack., and yes, we agree that for a few hours there was definitely something out of the ordinary occurring. 
The 'attribute' displayed, 'tcpinOutofOrder%', is a number we get  by doing this equation -  .TCPINOUTOFORDER / TCPSEGMENTSRECVD which provides the % of segment inout of order.
 
Look at the data points to see how we came to that number,  focusing on "tcpInOutofOrder" and   "tcpSegmentsRecvd"  attributes by doing the following:
1. =/perf  
2.  s    Protocols and Ports        Stack IP, TCP, and UDP  
3.  s    TCPIP
4   h     tcpInOutofOrder
 
 5. Tab down to Friday at those times.

Also do the same for the other attribute:
1. h     tcpSegmentsRecvd  
 
The raw data for these numbers is coming from the IBM EZBNMIFR API, from the GLOBSTAT command.
 
The problem occurred for a few hours and and then appears to have corrected itself.
At this point we can see the data indicating that a problem did exist, but at this point there is no way to determine cause.