Browse Prior Art Database

Flush Optimization for Buffered Devices

IP.com Disclosure Number: IPCOM000117284D
Original Publication Date: 1996-Jan-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 86K

Publishing Venue

IBM

Related People

Price, HG: AUTHOR

Abstract

Buffered devices can receive data from many sources. On receipt of this data, it is appended to the output buffer. The data in the buffer is flushed out either when the buffer is physically full or when a particular user requests this. These requests can be expensive in its consumption of CPU resource, and the user is usually sensitive to the response time.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Flush Optimization for Buffered Devices

      Buffered devices can receive data from many sources.  On
receipt of this data, it is appended to the output buffer.  The data
in the buffer is flushed out either when the buffer is physically
full or when a particular user requests this.  These requests can be
expensive in its consumption of CPU resource, and the user is usually
sensitive to the response time.

      At one end of the spectrum, there is a need to wait until the
buffer is physically full before it is flushed, so that the CPU usage
is minimized.  But this would usually cause many users to have to
wait, often longer than is acceptable.  At the other end of the
spectrum each flush request could be acted upon immediately, keeping
the user response time to a minimum at the expense of CPU usage.

      The described process forces each flush request to wait for a
short period, with out adversely affecting the user response time.
During this short period, there is a reasonable likelihood, on a busy
system, that other flush requests will be received, thereby
increasing the buffer utilization on the subsequent flush out.  Flush
requests that are received during the forced wait period share the
current wait period.

The following objects are defined to model the relative cost
attributes of the device:
  o  n - the average number of flush requests per second
  o  p - the forced delay period
  o  b - the base cost of a single flush request preparation
  o  l(p) - flushed block length.  This is expected to increase with
p
  o  f(l) - the cost of a single flush operation.  This is expected
to
      increase almost linearly with l.
  o  l1 - the average length of a flushed block when p is 0 (i.e.,
      without the forced-delay mechanism).
  o  l2 - the average length of a flushed block when p is greater
than
      0 (i.e.,  with the forced-delay mechanism).
       NB - l2 = (n/m)*l1
  o  e - the extra cost of a flush request preparation due to the
      forced-delay mechanism.
  o  r(p) - the value of the loss of response rate expressed in terms
      of cost.  This is expected to increase exponentially with p
  o  m(n,p) - the average...