Browse Prior Art Database

Improved Buffer Alarm

IP.com Disclosure Number: IPCOM000019492D
Original Publication Date: 2003-Oct-25
Included in the Prior Art Database: 2003-Oct-25
Document File: 4 page(s) / 143K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

In an information and communication environment, sensitive data, like e.g. data used for charging, often has to be stored on an external device (e.g. a hard disk), or has to be transported to an external entity (e.g. a post-processing center). If the external device is temporarily not available or the transport to the external entity is broken down, it has to be ensured that the data doesn't get lost. Therefore, the data is buffered, i.e. it is kept in a volatile memory until it can be successfully stored or transported. Throughout this paper it is assumed that the application generating the data (Process 1) is running independently of the process that is responsible for the transport and for releasing the buffers (Process 2). The capacity of the volatile memory is limited. To enable service personnel to take appropriate actions, it is important that a threatening loss of data is reported in time. One way to avoid data loss is to monitor alarm messages for link or device outages. The disadvantage of this method is that if the outage lasts only for a short period of time, an intervention of the personnel might not be necessary. Another method is to raise an alarm as soon as a certain preset threshold for the number of occupied buffers is exceeded. The problem here is that the alarm might be raised too late if a complete failure occurs when the number of occupied buffers is still low and the filling rate is very high.

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 47% of the total text.

Page 1 of 4

S

© SIEMENS AG 2003 file: 2003J10444.doc page: 1

Improved Buffer Alarm

Idea: Karel van Daele, BE-Ghent; Robert Heynze, BE-Ghent

In an information and communication environment, sensitive data, like e.g. data used for charging, often has to be stored on an external device (e.g. a hard disk), or has to be transported to an external entity (e.g. a post-processing center). If the external device is temporarily not available or the transport to the external entity is broken down, it has to be ensured that the data doesn't get lost. Therefore, the data is buffered, i.e. it is kept in a volatile memory until it can be successfully stored or transported. Throughout this paper it is assumed that the application generating the data (Process 1) is running independently of the process that is responsible for the transport and for releasing the buffers (Process 2).

The capacity of the volatile memory is limited. To enable service personnel to take appropriate actions, it is important that a threatening loss of data is reported in time. One way to avoid data loss is to monitor alarm messages for link or device outages. The disadvantage of this method is that if the outage lasts only for a short period of time, an intervention of the personnel might not be necessary. Another method is to raise an alarm as soon as a certain preset threshold for the number of occupied buffers is exceeded. The problem here is that the alarm might be raised too late if a complete failure occurs when the number of occupied buffers is still low and the filling rate is very high.

The here proposed algorithm also takes into account at which rate the buffers are filled and is thereby able to estimate the time left until a loss of data occurs. To achieve this, Process 1 has to keep track of the Transmitting Time (Tx), i.e. the time at which it sends a buffer request to Process 2, and the number of not released buffers (N), while Process 2 stores the Buffer Release Time (Rx) of the last successful transfer / storage of a buffer (i.e. the timestamp of the last buffer release) and the number of filled buffers (F). Whenever Process 1 sends a buffer request, Process 2 returns the values of Rx and F to Process 1 (Fig 1).

If a buffer has been released after the last buffer request, i.e. Rx>Tx, this implies that the number of filled buffers has not increased. Process 1 then stores the time of the new request as the new value for the Transmitting Time and resets N to zero (Fig. 2). If no release has taken place after the last buffer request, i.e. Rx<Tx, it means that the number of not released buffers has risen by one, and thus Process 1 raises the counter (N) accordingly. In this case Tx is not overwritten by the new value (Tx+1) of the Transmitting Time. Every time Process 1 requests a buffer slot, it checks whether a release has taken place, and, if this is not the case, raises the counter (Fig. 3 and 4).

The speed at which the number of unreleased buffers increases can now be...