Home
VOV Subsystem Administrator Guide
This manual provides information about managing a VOV project, including starting the server and connecting computing resources such as computers and licenses.
Taskers
A tasker is a VOV client that provides computing resources, specifically CPU cycles, to the vovserver.
Autokill of Jobs by vovtasker

Welcome
What's New
View new features for VOV Subsystem 2025.1.0.
Overview
Discover the workspace, licensing and installation, and training.
VOV Subsystem Tutorials
Discover VOV Subsystem functionality with interactive tutorials.
VOV Subsystem Administrator Guide
This manual provides information about managing a VOV project, including starting the server and connecting computing resources such as computers and licenses.
- Client/Server Architecture
  All of Altair Accelerator's products are based on a client/server architecture to support concurrent activities, team coordination, distributed data management, and distributed processing. The program vovserver runs in the background as a service to implement the main product features. It is the server.
- VOV Projects
  A "project" is a named collection of jobs, together with all the files that are used and produced by those jobs. The contents of VOV projects can be custom organized.
- VOV Registry
  The VOV Registry contains the list of all projects known to an installation of Altair Accelerator software. The registry is used by the vovproject command, and stores metadata such as the host machine and port number of a project.
- Get Started
- Start and Configure the Server
- Connect to a Project
- Stop the Server
- Recovery and Redundancy
- Files, Equivalences, Exclusions
  The files used in a project reside in one or more directories spread all around your filesystems. Each logical name defined in the equiv.tcl file implicitly declares the root of a workspace. You can browse the workspaces using the browser interface.
- Taskers
  A tasker is a VOV client that provides computing resources, specifically CPU cycles, to the vovserver.
  - The taskers.tcl File
    The taskers.tcl file describes the taskers for a project.
  - vtk_tasker_define
    There are many options that can be used with vtk_tasker_define and vtk_tasker_set_default.
  - vovtaskermgr
    The main way to start, configure, and stop the taskers is with the vovtaskermgr command. This command acts relative to the VOV-project enabled in the shell where it is issued.
  - Tasker ID
    Each tasker is an object in the VOV database and therefore it has its own VovId.
  - Tasker Attributes
    A tasker is characterized by several attributes. These attributes are controllable by means of the command line arguments to the vovtasker binary as well as by means of the procedure vtk_tasker_define in the taskers.tcl configuration file for a VOV project.
  - Tasker Configuration Parameters
  - Tasker Power
    Upon startup, the vovtasker computes the raw power of the CPU on the current host by timing a known test routine consisting of a balanced mix of integer, double and string operations. The power is inversely proportional to the time it takes to execute the test routine.
  - Autokill of Jobs by vovtasker
  - Tasker RAM Saturation
  - Connect a Single Tasker
  - Tasker Status
  - Monitor Taskers
    To monitor the activity of the taskers, use either vsm from the CLI, or click Console > Vov Monitor from the GUI.
  - Tasker Resources
    The resources offered by a tasker are represented by a space-separated list of tokens. Resources can be explicit or symbolic.
  - The taskerClass.table File
  - Time-Variant Taskers
    Time-variant taskers resources can be configured using Tcl. Any procedure can be defined in the namespace VovResources and then used to compute the resource list.
  - Predefined VovResources:: Procedures
    This section describes the predefined procedures that can be used to characterize the taskers in your farm in a time-variant fashion. To use these procedures, you have to use them as resources for a tasker.
- Tasker Policies
- Interfaces to Accelerator, SGE, LSF, and Others
  FlowTracer can be used also as a front end to an existing batch processing system (BPS), for example, Accelerator, LSF, SGE, SGEEE, etc.
- Advanced Tasker Topics
- Resource Management
  Altair Accelerator includes a subsystem for managing computing resources. This allows the design team to factor in various constraints regarding hardware and software resources, as well as site policy constraints.
- IT Administrator Topics
VOV Subsystem Reference Guide
EDA Tool Integration Guide
This document is a collection of techniques that have proven to be useful when applying FlowTracer in Electronic Design Automation.

View All Altair Accelerator Help

Autokill of Jobs by vovtasker

If a job has the autokill field set to a positive value, the job will be killed by vovtasker/vovtasker if its duration exceeds the autokill value. The autokill field can be applied to any job of which the status is not Failed or Done.

The check for this condition is done by vovtasker every minute. This frequency is controlled by the "tasker update" value).

If a job is to be auto-killed, the vovtasker can use one of three methods:

Direct: the tasker sends the job the signals TERM,HUP,INT,KILL. These can by overridden by defaultStopSignalCascade and defaultStopSignalDelay that can be set in policy.tcl, etc.
If NC_STOP_SIGNALS and/or NC_STOP_SIG_DELAY are set, then these will be used instead. The format of NC_STOP_SIGNALS can be a comma separated list. Each signal name such as "USR1", or the format ":SIGNAL:includerx:excluderx:skiptop"
that is,
```
nc run -D autokill 10s -P
NC_STOP_SIGNALS=USR1::python:1,TERM,KILL -P
NC_STOP_SIGNAL_DELAY=1
```
send USR1 excluding any Python processes that are part of the job. Then send TERM and then KILL with a delay of 1s between signals.
VOV_STOP_SIGNALS and VOV_STOP_SIGNALS_DELAY work similarly to NC_STOP_SIGNALSand NC_STOP_SIG_DELAY
NC STOP: the tasker calls nc stop JOBID; this only works for tasker that are running within Accelerator; this method honors the values of NC_STOP_SIGNALS and NC_STOP_SIG_DELAY.
VOVSTOP : the tasker calls vovstop -fJOBID to kill the job.

The method used to autokill the jobs can be controlled on each tasker, meaning that all jobs on that tasker, if they need to be autokilled, will be killed with the same method.

Currently there is one way to change the autokill method on a tasker, and that is with this magic incantation:

% vovsh -x 'vtk_tasker_config TASKERNAME_OR_ID autokillmethod VALUE'

where VALUE can be one of the following keywords:

direct
ncstop
vovstop

In reality, only the first letter of the keyword is used, i.e. 'd', 'n', 'v'. Anything else maps silently to 'direct'.

Examples:

% vovsh -x 'vtk_tasker_config lnx0123 autokillmethod ncstop'
% vovsh -x 'vtk_tasker_config lnx0123 autokillmethod n'
% vovsh -x 'vtk_tasker_config 00234567 autokillmethod direct'