Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-71-1479563.1
Update Date:2017-05-19
Keywords:

Solution Type  Technical Instruction Sure

Solution  1479563.1 :   SL3000/SL8500 - What is Acceptable Network Status Error Drop Out Rate for Rail Issues  


Related Items
  • Sun StorageTek SL3000 Modular Library System
  •  
  • Sun StorageTek SL8500 Modular Library System
  •  
Related Categories
  • PLA-Support>Sun Systems>TAPE>Tape Hardware>SN-TP: SL3000-8500 Library
  •  




In this Document
Goal
Solution
References


Applies to:

Sun StorageTek SL3000 Modular Library System - Version Not Applicable and later
Sun StorageTek SL8500 Modular Library System - Version Not Applicable and later
Information in this document applies to any platform.

Goal

SL3000/SL8500 - What is Acceptable Network Status Error Drop Out Rate for Rail Issues

Solution

Updated to Include Possible Controller Impact - Issue the command "stats network" from the CLI and examine the columns "packets", "frame" and "overruns".  Frame is the total frames received with errors. 
Acceptable error rates are not well defined.  As a general rule of thumb, if the frame errors are greater then 10% of the packets, there is a need to investigate the possibility of a rail termination or communication problem.
Typical failures rates are below 1%. Excessive communication failures can result in unnecessary and repeated H-Bot replacements to resolve rail resets, timeouts, 5010 and 5070 errors.
Extreme levels of errors have the capability of overwhelming the controller and causing it to become unresponsive.  

Experience has shown any time there is a significant number of frame errors from the stats network command, there is a potential for problems.  Especially if one rail has much higher frame error counts then other rails.

The problem with using stats network is the only way to clear the counters is to reboot the library.  The data being seen may be very old and not relevant to the issue being worked.

Terminators and the security of their connections were and still are a major factor in high error counts. A faulty HBS card or one electrically noisy H-Bot can cause high error rates on the rail.

Contaminated copper strips are also a possibility. However, graphite debris on the copper strips is normal and should be expected.  When it becomes excessive, or other contamination is apparent, it must be taken on a case by case basis. 
In those situations, contact an area specialist for help or open an SR with Backline Support.

Examine the columns "packets" and "frame". Frame is the total frames received with errors. Acceptable error rates are note well defined. As a general rule of thumb, if the frame errors are greater then 10% of the packets,
there is a need to investigate the possibility of a rail termination or communication problem.

Keep in mind there could be other causes for the high error rate other then dirty copper strips. Terminators were and still are a major factor into a high error count.

None of this is to say cleaning the copper strips will not fix the problems. Graphite debris on the copper strips is normal and should be expected. When it becomes excessive,
it must be taken on a case by case basis. In those cases, contact an area specialist for help or open an SR with Backline Support.

Refer to SL8500/SL3000 - Cleaning Requirements on Rails (Doc ID 1479467.1) for cleaning information.

@Provided by Kevin Luther


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback