Periodic process timer

Details Periodic process timer Periodic process timer

1997-08-21

2002-05-07

Courtenay, III, St. John (Department: 2151)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C379S265030, C702S182000, C713S502000, C709S241000

Reexamination Certificate

active

06385637

ABSTRACT:

BACKGROUND OF THE INVENTION
The present invention relates generally to a method for timing computer processes or tasks and more specifically to a timing method for accurately timing software processes in a multitasking operating system of an automatic call distributor system.
Automatic call distributor (ACD) systems are typically used by businesses to automatically route incoming customer telephone calls to available sales agents. ACD systems generally include a multiport switch controlled by a central processing unit to interconnect external telephonic units of an external telephonic network with internal agent telephonic units. An example of such an ACD system is disclosed in U.S. Pat. No. 5,140,611 issued to Jones et al. on Aug. 8, 1992, entitled “Pulse Modulated Self-Clocking and Self-Synchronizing Data Transmission and Method for a Telephonic Communication Switching System,” owned by the common assignee of the present patent. The disclosure of U.S. Pat. No. 5,140,611 is hereby incorporated by reference.
ACD systems include at least one central processing unit and often, include many distributed processing units located on various hardware circuit cards of the system. Usually, one processing unit is responsible for the execution of the operating system, although parallel processing permits multiple processors to “share” the execution of software tasks. For purposes of illustration only, the below-described subject matter will refer to a single central processing unit, although multiple processing units may be implemented. ACD systems are complex and are typically controlled by a real-time multitasking operating system. Real-time multitasking operating systems use various methods to allocate processing time among various tasks of the ACD. One known method of allocating time among the various processes is to perform a “context switch” at predetermined time intervals. For example, an interrupt occurring every ten to twenty milliseconds may be used to cause a context switch. That is, every ten or twenty milliseconds, the current task being executed is temporarily suspended and another task is begun. Usually, this occurs on a “time-slice” basis so that all tasks are eventually serviced. There are numerous known schemes used to further “fine-tune” the context switching, such as priority order, rotating priority order, round-robin switching or a combination of priority and round-robin scheduling. Additionally, some tasks may be designated as “non-interruptible” or “non-switchable” tasks during its entire execution time or a portion thereof, depending upon the critical nature of the task. Accordingly, real-time multitasking operating systems utilize an appropriate method for allocating computer processing time such that all software processes are permitted to perform their function.
However, known real-time multitasking operating systems may become overloaded or overburdened if required to perform too many tasks. In such a situation, response time will suffer which could lead to sluggish performance, system failures, or “crashes.” In ACD systems, this may occur when the system is overloaded by routing more than a maximum number of telephone calls through the ACD system, adding too many agents, or requiring the system to perform additionally tasks, such as report generation, and diagnostics and the like that are beyond its capacity. To prevent overloading the ACD system, the processing time devoted to the processes must not be exceeded. By knowing the processing time devoted to each task, the engineers and technicians can monitor the available “processor power” to determine whether the central processing unit can adequately handle the required processes. This is particularly useful when additional system tasks are proposed but not actually implemented. This typically occurs when a customer wishes to know how the ACD system will perform given added burdens. A need exists for a method capable of determining whether the capabilities of an ACD system are approaching or have exceeded the processing limits of the central processing unit as additional burdens are placed on the ACD system in real-time. A need also exists for a method capable of determining which process in a multitasking operating system uses a disproportional amount of processing time.
The available processing power is determined by the combination of the type of computer, microprocessor, or “chip” used, the speed of the microprocessor (frequency or clock speed), the efficiency of the software instructions (number of operands per instruction, number of bits in the instructions), input/output structure of the system, frequency of interrupts and the interrupt structure, and the like. Additional tasks may be added to the system and the scope or frequency of existing tasks can be increased if sufficient processor power exists.
However, known methods for determining whether sufficient processing power exists to handle additional capacity in an ACD system are inadequate. Typically, the tasks or increased load are added to the ACD system and technicians monitor the system to determine if any adverse results follow. If the efficiency of the system is reduced by more than an acceptable amount, the tasks are removed from the ACD system until performance is acceptable. This is essentially a “trial and error” approach.
Another known method utilizes a software command that is executed on an interrupt basis, for example, every ten milliseconds. This method provides an indication of the available processing “power.” Every ten milliseconds an interrupt occurs and an accumulator function is executed which simply determines which process was running at the time that the ten millisecond interrupt occurred. A software accumulator associated with that particular process is then incremented (e.g., a “tick” is added to the value in the accumulator). Each individual process or task has its own software accumulator and each tick in the accumulator represents an addition of ten milliseconds of time. Since the interrupt occurs every ten milliseconds., it is assumed that the interrupted process had been executing for ten milliseconds. Accordingly, its accumulator is incremented.
However, this method suffers from significant disadvantages. First, accurate timing cannot be achieved because the “granularity” or resolution of the timing function is too large. A relatively large value, for example, ten milliseconds, is used so as not to overburden the system with the accumulator process itself. If the accumulator process is executed too often (e.g., more than every ten milliseconds), it becomes part of the problem leading to sluggish system performance. Because of the large granularity, errors in time accumulate and become significant such that an accumulated time associated with a particular process is not an accurate reflection of the actual time devoted to the particular process. This known method is only adequate to identify a process that grossly and disproportionately uses processing time.
A second serious disadvantage of such a method is that the software accumulator for a particular process is only incremented if that process was running at the time that the ten millisecond interrupt occurred. For example, if process “A” was executing for five milliseconds, then process “B” was begun and the ten millisecond interrupt occurred, the software accumulator associated with process “B” is incremented while the software accumulator for process “A” is not modified because the accumulator function did not “know” that process “A” had been executed. This problem is referred to as a “boundary problem” and leads to serious distortions in the amount of execution time reported for each process. Thus, the engineer or technician cannot rely upon the information provided and cannot determine the source of the problem, assuming that the problem is not an obvious problem where one process is the continuous source of grossly disproportionate time consumption.
A third significant disadvantage of the above-described software accumulator function is that it must be exec

Affiliated with

Also associated with

Rating

Periodic process timer does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Periodic process timer, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Periodic process timer will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2848194