Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

DYNAMIC FEATURE ADDITION/ELIMINATION FOR AUTO-CPU-SPEED COMPENSATION

IP.com Disclosure Number: IPCOM000007444D
Original Publication Date: 1995-Jul-01
Included in the Prior Art Database: 2002-Mar-27
Document File: 1 page(s) / 82K

Publishing Venue

Motorola

Related People

David A. Soussan: AUTHOR

Abstract

BACKGROUND OF THE PROBLEM: Today's software is increasingly suffering From more features which make a program more com- plex and require more CPU horsepower in order to run. Anyone that has a 68030-based Macintosh, worked with Microsoft's Excel 2.2 and upgraded to 4.0 has experienced this first-hand. For our RF Analyzer product the features we want to support cause us to fall into the same CPU-speed limiting trap. The product needs to be usable on a range of PCs from 80286s through Pentiums.

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

Page 1 of 1

Technical Developments

DYNAMIC FEATURE ADDITION/ELIMINATION FOR AUTO-CPU-SPEED COMPENSATION

by David A. Soussan

BACKGROUND OF THE PROBLEM:

  Today's software is increasingly suffering From more features which make a program more com- plex and require more CPU horsepower in order to run. Anyone that has a 68030-based Macintosh, worked with Microsoft's Excel 2.2 and upgraded to
4.0 has experienced this first-hand. For our RF Analyzer product the features we want to support cause us to fall into the same CPU-speed limiting trap. The product needs to be usable on a range of PCs from 80286s through Pentiums.

DESCRIPTION:

  In order to support the range of CPUs available, this technique will in real-time automatically turn off various features in order to maintain as much functionality as possible based on the system the program is running on. This "ordered feature shut- down" can be preset to a certain priority scheme as well as user-definable. There does not need to be any CPU-speed measuring algorithm as these do not indicate how much horsepower is available to the program on a continuous basis as other things (interrupts, disk latency, network bandwidth/response delays) may affect the total system's throughput. Instead, another technique must be used such as:

  1. Watching various buffers and their percent- full status; the more full the buffer gets, the more features can be shut down before a buffer overflow occurs. This is our preferred embodiment; detailed example below.

  2. Timing how long a segment of the program takes; not doing certain operations if delays over a threshold occur (e.g., if a screen update takes too long to do every time, only do it every N seconds or every time nothing else is happening as opposed to every time something on the screen should change.)

  3. Watching for mouse...