Performance Monitoring Using Cycle Mode | HCL Blogs

Performance Monitoring Using Cycle Mode and Marathon Runs

Performance Monitoring Using Cycle Mode and Marathon Runs
January 07, 2015

Cycle Mode

Image courtesy:,3.html

Software is usually run continuously, without being rebooted and with maximum features enabled. Along with this, private bytes are also continuously monitored as a key input for performance monitoring. For one of the product lines, we have the cycle mode enabled, wherein for the continuous runs of Recipe (i.e.; the process information), the software is limited to unlimited runs simply by applying intelligence logic where the Processed carrier behaves as an Unprocessed carrier. The carrier, on reaching the Load lock is moved back to the Reactor with the same recipe scheduled for the earlier run – ready for another layer of growth via the Buffer shelf.

Brief description of the process

Once it reaches the load-port (where the Carriers are loaded with raw wafers, the Cycle mode is checked. Once the Flag indicates true for Cycle mode, the internal logic converts the Processed Wafer (indicated in Green) to the Unprocessed Carrier (Blue). However, in case it is false option, the Processed Carrier is removed from the tool.

Once the color changes, an auto Job ID is set to the carrier with respect to the time stamp applied to it. Then, the recipe applied for the earlier process (stored in a buffer) gets applied to the Unprocessed carrier  and moves into the same reactor in which it has completed one run again.

The Marathon runs collect the private bytes and processor time (CPU usage) data for the components. Based on the above data points collected over a period of 50-60 runs on each reactor, the run per growth and overall growth of the memory is calculated using the below formula to trace the growth of the memory for an application. The performance monitor of the CPU helps in the scaling of effective running of software over a period of time.

{[(Memory at the end of the recipe execution – Memory at the start of the recipe execution)/1024]}/1024 = Memory growth in Mbs

The three major parameters those are monitored are as shown in the below chart. For a run from 1 to N:

Marathon Run

Above: Memory Growth run specific, Per run and Overall growth

Why is this needed?

Today, production of LEDs requires continuous epitaxial growth of the chemical vapors deposited on the substrate for a very long time (MOCVD). It can extend to days and even weeks. This often causes a lag in the application performance as a fixed initial memory allocation is made to the application during start up.

The algorithm is configured such that it expects the memory to be released after every run of the recipe which is used for the production of chemical coated substrate. Sometimes, this does not happen and it leads to continuous consumption of limited/fixed memory allocation which again leads to burdening of memory usage, stopping basic functionalities to work and ultimately leading to software crash. This is when application monitoring is most necessary. As part of Software Testing, it is a must to take up the task of setting up the production environment and employ cases used in real time production environment. Software Reliability Metrics is a must for any product software in this current software Industry.

Learning from the current project

One of the key take away from the current project has been that even in an idle tool, a lot of chemicals are always kept for supply and very less maintenance time is accepted.

The downtime of the tool for the production should be as low as possible as it can lead to huge losses. Raw materials and tools should be used effectively and to the maximum extent. In the process, high software reliability will be ensured. Application performance management is thus becoming one of the primary focus for all the Product equipment manufacturing companies throughout the world and has been recognized as one of the key types of software testing.


For software performance monitoring, certain parameters like processor time, also known as CPU Usage and Private Bytes, Thread Count, Available Bytes, Used Bytes, etc. are used in specific applications.

Simultaneously, data with application is monitored against the processor time:

Metrics plotted against applications(sample graphs)

Graph Displaying Version wise Private

Above: Graph Displaying Version wise Private bytes for Software applications

Below: Application specific analysis technique

Application process

This depicts the improvement and helps in detecting issues (if any) with respect to performance lags/memory leaks and works to fix the same.


The major benefit of this process is better software reliability (runs for months together).This has also led to a much higher profit and throughput with increase in threshold performance.