Browse Prior Art Database

Good/Bad Counter Handling

IP.com Disclosure Number: IPCOM000060414D
Original Publication Date: 1986-Apr-01
Included in the Prior Art Database: 2005-Mar-08
Document File: 2 page(s) / 36K

Publishing Venue

IBM

Related People

Dunn, MR: AUTHOR

Abstract

An effective method to handle good/bad counters for reporting error conditions is described. Many devices count how many good and bad operations take place during the activation of a hardware device. There has been no effective way of using these counters to determine when a condition occurs that should be logged as an error condition and/or requires operator intervention/notification. The problem is to define threshold logging criteria. Defining a ratio (%) between good/bad doesn't protect good count runaway nor provide protection from premature logging. An example of good count runaway is illustrated below. Assume that a design defines that when a good/bad count ratio is > 5% an error should be logged.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 80% of the total text.

Page 1 of 2

Good/Bad Counter Handling

An effective method to handle good/bad counters for reporting error conditions is described. Many devices count how many good and bad operations take place during the activation of a hardware device. There has been no effective way of using these counters to determine when a condition occurs that should be logged as an error condition and/or requires operator intervention/notification. The problem is to define threshold logging criteria. Defining a ratio (%) between good/bad doesn't protect good count runaway nor provide protection from premature logging. An example of good count runaway is illustrated below. Assume that a design defines that when a good/bad count ratio is > 5% an error should be logged. In this case, the good count had gotten so large that the bad counter would need to log more than 400 consecutive errors (5% of 9980) before the operator would be notified. An example of premature logging is shown below, assuming the same assumptions as above. In this case, logging will take place during initial activation of resource because an error occurred before the good count could achieve a reasonable value (i.e., 50). To avoid these problems, the following rules for defining counter values are employed. A. Bad Threshold What value of consecutive retries should cause a permanent error notification/log to occur (defined by hardware designer or customer-generated parameter). B. % Ratio Good to Bad Count What ratio of good to bad cou...