This chapter consists of the following:
Video Server Toolkit (VST) is normally started automatically when the VST server boots. In a development environment, you may choose to disable automatic startup and start it manually instead.
This section explains how to start VST in the following sections:
 | Note: For information on booting from a backup plex, see “Configuring for Booting From a Backup Plex” in Chapter 9. |
By default, when VST is installed, it does not enable itself to be automatically started when the system boots. As superuser, you can configure VST to start automatically at boot time using chkconfig with the vtr option. The following enables automatic startup:
# chkconfig vtr on |
The following disables automatic startup:
# chkconfig vtr off |
You must be root to start VST. Start VST with
# /usr/vtr/bin/vtrstart vtrstart: Starting video server |
| Note: The message is displayed only if the system has verbose logging enabled (chkconfig verbose on). |
If VST is already running, vtrstart displays an error:
vtrstart: Video server is already running (use -f to force restart) |
As indicated, to stop the VST instance currently running and start a new VST instance, add the -f option:
# /usr/vtr/bin/vtrstart -f vtrstart: Stopping video server vtrstart: Starting video server |
When the VST daemon vtrd starts, it reads the configuration file /usr/vtr/config/vtrd.conf. The daemon vtrd is the VST server daemon that manages the VST server processes.
The default installation operates normally without any change to the startup options. However, you can change the startup options for vvtr, the VST server process, by editing /usr/vtr/config/vtrd.conf and adding them immediately after the program path, /usr/vtr/bin/vvtr.
Table 8-1 describes the startup options for vvtr.
Table 8-1. VST Server Process (vvtr) Startup Options
Option | Description |
|---|---|
-l logopts | Sets the log options, which control the format of the messages written to the log. If this option is omitted, each message contains the severity code, a timestamp, the process ID, and the text of the message. The following may be specified for this option: -l l, do not include the severity code in each log message “VST Log Message Structure” for more information about log message format. |
-p | Specifies that VST should not run at high priority (p). If this option is omitted, VST runs at high real-time system priority to ensure no interruptions in video/audio input or output. Include this option only at the direction of VST support personnel. |
You can use vtrstat to check whether VST is running on the system. If VST is not running, vtrstat displays the following message:
# vtrstat Video server on <host> is stopped |
If VST is running and responding to MVCP connections, vtrstat displays
Video server on <host> is running. |
For additional VST status information displayed by vtrstat, see “Monitoring the System”.
An optional graphics port is available on O2 workstation that allows you to see the outgoing video in the VST X window in the graphics display. This window is sized to display a 625/50 video frame with non-square pixels (720 x 576). If you are playing video with a smaller image size, the image is centered within the VST X window.
| Note: If you are playing video with non-square pixels (CCIR601 timing), for example a 525/59.94 video frame, the aspect ratio in the graphics window is incorrect; pixels are square on the graphics display and VST does not rescale the image. |
The graphics window is enabled by default on O2 workstation. To disable it, edit /usr/vtr/config/device-defaults/mvp and set vtr.media.graphics.enabled to false.
If you wish to use the graphics port, you cannot start VST automatically at boot time. The vvtr X Window appears only when you use /usr/vtr/bin/vtrstart to start VST.
To disable automatic startup, enter this command;
# chkconfig vtr off |
The VST logging feature provides a mechanism for storing a text record of events that occur during operation of the system. The default logging configuration generally records only events that are generated by various error conditions, but you can enable additional logging to help track and trouble-shoot VST behavior.
This section explains
Each VST log message has the following format:
c dd-hh:mm:ss.mmmmmm pppp <log message> |
where
c is the severity code of the message
dd is the day of the month
hh:mm:ss.mmmmmm is a time stamp that indicates when the message was written
pppp is the process ID of the process that wrote the message to the log
log message is the actual text message
Table 8-2 shows the VST log severity levels and codes, which are listed in decreasing order of severity.
Severity Level | Severity Code | Description |
|---|---|---|
P | Panic condition. | |
A | A condition that should be corrected immediately, such as a corrupted system file. | |
C | A critical condition that has system-wide impact, such as a hard device error; immediate action is required. | |
E | A problem that needs correcting, but does not require immediate action. | |
W | Possible problem, but could be a transient problem that corrects itself. | |
N | Condition that might require attention, but isn't an error condition. | |
I | Informational message. | |
n | Information message that normally is of use only to engineers for debugging; can be Debug1, Debug2, or Debug3, with Debug3 producing the most amount of debugging information. |
The following is an example of a message that has a severity code of 2 (Debug2 severity level). The message was written on day 14 of the month at the time that is shown in the message, and the ID of the process that wrote the message is 8254:
2 14-22:23:50.316766 8254 mvcp/ninety9 <-- 100 VTR Ready |
The following example shows a Notice-level message.
N 29-09:26:11.490919 3064 U1 Unit ERROR (err=22): Clip timecode type not know |
The following example shows an Info-level message.
I 29-09:26:12.758644 3065 (littlered_1) Timecode input acquired tc=09:27:35.02 (offset=* -27000000) |
The following example shows a Warning-level message.
W 28-14:06:56.807983 35339 U16(DIVO_DVC_2) Video input missing |
Logging is configured by setting the value of the following controls in the system defaults file /usr/vtr/config/system-defaults/main:
vtr.main.log_level.file
vtr.main.log_level.syslog
For example, to enable increased logging by including the first level of debug events in the events that are logged to the server log, /usr/vtr/adm/logs/vtrlog, include the following control setting in the main system defaults file:
vtr.main.log_level.file 1 |
The value of the control is relative to the Info log event severity. Positive values enable more verbose logging (1 = Debug1, 2 = Debug2, ...); negative values disable all but the more severe events (-2 = Warning, -3 = Error, ...).
Log rollover is the practice of saving the current log file and restarting logging into an empty log file. Rollover avoids the problems of running out of disk space and of having a list of log messages too long to handle easily.
VST manages the vtrlog server log file. By default, the log file is saved and a new log file begun every night at 2:00 a.m. if the log file is at least 10 MB. The default number of log files retained on the system is ten.
The command rotatelogs is used to manage the log files and is executed by the system's cron job handler at the right time. Table 8-3 shows the list of available options.
Table 8-3. rotatelogs Command Options
Option | Specifies | Default Value |
|---|---|---|
-b | Log filename | vtrlog |
-d | Log file directory | /var/adm/vtr/logs |
-h | Lists these options |
|
-l | Daemon to notify | vtrd |
-m | Maximum number of backups retained on the server | 10 |
-s | Minimum log file size to trigger rollover | 10 MB |
-D | Debug level | Off |
To change any defaults (such as the time of the rollover or the log size), the crontab entry of rotatelogs in the system must be edited (as root, using crontab -e). This entry was installed as part of the initial VST installation by an exitop.
For example, to retain the last 20 log files on a machine, the rotatelogs entry in crontab must look like:
1 2 * * * /usr/vtr/bin/rotatelogs -m 20 |
The debug option is off by default. It can be turned on using the -D option. There is only one level of debugging information (on).
Once Video Server Toolkit (VST) is installed and running, you can monitor its operation using the tools mentioned in this chapter. Two tools, vtrstat and mcstat, work directly with VST. You can also use standard SGI IRIX tools to monitor various system resources.
This chapter describes how to monitor VST in the following sections:
vtrstat is a command-line tool that tells you:
Whether or not VST is running
Which units are open, if the -units option is used
Which media ports are available, if the -ports option is used
Example 8-1 shows an example output of vtrstat.
vsta 7# /usr/vtr/bin/vtrstat -units Video server on vsta is running. Unit Owner Port Clip Function Location ---------------------------------------------------------- U1 louth DIVO_0 d/REC12 STOP 01:04:30.05 U2 louth DIVO_0 * STOP * U3 louth DIVO_1 d/rPOP CUE 00:00:00.00 U4 louth DIVO_1 d/rSEL STOP 00:00:00.00 U5 louth DIVO_1 d/REC01 STOP 01:04:30.06 U6 louth DIVO_1 * STOP * U7 louth DIVO_0 d/rSEL CUE 00:00:00.00 U8 louth DIVO_0 d/rSTOK STOP 00:03:30.01 U9 louth DIVO_7 d/rJOR CUE 00:00:00.00 U10 louth DIVO_7 d/rSEL STOP 00:00:00.00 U11 louth DIVO_3 d/rPOP CUE 00:00:00.00 U12 louth DIVO_3 d/rSTOK PLAY 00:03:02.29 U13 louth DIVO_4 d/rSEL CUE 00:00:00.00 U14 louth DIVO_4 d/rSTOK STOP 00:00:00.00 U15 louth DIVO_5 d/rSEL CUE 00:00:00.00 U16 louth DIVO_5 d/rSTOK STOP 00:03:30.01 vsta 8# /usr/vtr/bin/vtrstat -ports Video server on vsta is running. # Port Type Description ---------------------------------------------------------- 1 DIVO_0 Video SGI XT-DIVO Digital Video Option 2 DIVO_1 Video SGI XT-DIVO Digital Video Option 3 DIVO_3 Video SGI XT-DIVO Digital Video Option 4 DIVO_4 Video SGI XT-DIVO Digital Video Option 5 DIVO_5 Video SGI XT-DIVO Digital Video Option 6 DIVO_6 Video SGI XT-DIVO Digital Video Option 7 DIVO_7 Video SGI XT-DIVO Digital Video Option 8 dq_0 Deck Diaquest Deck Control |
A description of these functions can be found in the Video Server Toolkit Developer's Guide in Chapter 11, “Completing Common Tasks Using MVCP Commands.”
mcstat graphically displays the activity of all units that are currently open on a VST server. It is recommended that you install vst_eoe.sw.base and vst_eoe.sw.tools on the SGI workstation you are using to monitor the VST server and run mcstat on that workstation instead of the server.
Figure 8-1 shows an example of mcstat's output when VST is running. When VST is not running, mcstat exits.
mcstat displays a list of all the media ports supported by the VST server. For each port, it displays all the units that are opened on that port; each unit is on a separate line.
The unit display includes the name of the unit, the unit owner information, the name of the clip currently loaded on the unit, the last function executed by the unit (or the one currently executing), the current clip time code, and the status of the function.
SGI provides a collection of monitoring tools that can be used with VST, including
sar: system activity reporter; reports operating system activity
gr_osview: graphical system monitor; graphically displays real-time usage of certain system resources
osview, a text version of gr_osview
Performance Co-Pilot (PCP): serves as an interface for existing reporting tools, such as graphing performance data over time
Before exporting media data recorded by VST to IRIX tools, you must manipulate the data. For more information about exporting media data, see Video Server Toolkit Developer's Guide .
sar, the System Activity Reporter, is an activity counter. The command line options allow you to specify the kinds of activities you want measured, such as disk utilization. To use sar, follow these steps:
Enable sar using the following command:
# chkconfig sar on
Reboot your system.
When your system reboots, the sar data collector starts.
Specify the system activity you want sar to measure; for example, to measure disk utilization, use a command similar to the following:
# sar -d 2 10
The -d command-line option specifies the display of disk utilization. The numbers, 2 and 10, specify how often you want to take reports. In this example, 10 reports are taken every 2 seconds.
| Note: For a complete list of sar command line options, see the sar(1M) man page. |
The following is example output of sar.
vsta 100# sar -d 2 10 IRIX64 vsta 6.4 02121744 IP27 12/19/1997 11:15:10 device %busy avque r+w/s blks/s w/s wblks/s avwait avserv 11:15:12 dks2d1 8 1.0 3 12002 0 0 0.0 28.3 dks3d69 8 1.0 1 12257 0 0 0.0 53.3 dks0d1 8 5.4 7 120 7 120 49.3 11.3 dks1d1 0 0.0 0 0 0 0 0.0 0.0 dks0d2 0 0.0 0 0 0 0 0.0 0.0 dks1d2 0 0.0 0 0 0 0 0.0 0.0 dks0d3 0 0.0 0 0 0 0 0.0 0.0 dks1d3 0 0.0 0 0 0 0 0.0 0.0 dks0d4 0 0.0 0 0 0 0 0.0 0.0 dks1d4 0 0.0 0 0 0 0 0.0 0.0 dks0d5 0 0.0 0 0 0 0 0.0 0.0 dks1d5 0 0.0 0 0 0 0 0.0 0.0 dks0d6 0 0.0 0 0 0 0 0.0 0.0 dks1d6 0 0.0 0 16 0 16 0.0 0.0 |
gr_osview provides a graphical display of system resources use. This display provides a real-time window into the overall operation of the system, as shown in Figure 8-2.
For more information about this utility, see its man page, gr_osview(1M)
osview is a text version of gr_osview. The following show example output of osview:
Osview 2.1 : One Second Average vcpqa2 10/02/98 09:30:25 #14 int=5s
Load Average 4MB pages 0 vidintr 0
1 Min 0.008 16MB pages 0 drop_add 0
5 Min 0.000 System Activity TCP
15 Min 0.000 syscall 206 conns 0
CPU 0 Usage read 3 sndtotal 0
%user 0.00 write 0 rcvtotal 0
%sys 1.20 fork 0 sndbyte 38
%intr 0.00 exec 0 rcvbyte 0
%sxbrk 0.00 readch 45 UDP
%idle 98.80 writech 78 ipackets 1
CPU 1 Usage iget 0 opackets 0
%user 0.00 Block Devices dropped 0
%sys 0.60 lread 0 errors 0
%intr 0.00 bread 0 IP
%sxbrk 0.00 %rcache 0.0 ipackets 1
%idle 99.40 lwrite 0 opackets 0
Wait Ratio bwrite 22.4K forward 0
%IO 0.0 wcancel 0 dropped 0
%Swap 0.0 %wcache 0.0 errors 0
%Physio 0.0 phread 0 NetIF[ef0]
System Memory phwrite 0 Ipackets 2
Phys 512.0M *Swap Opackets 0
kernel 26.7M *System VM Ierrors 0
heap 7.7M Memory Faults Oerrors 0
stream 48.0K vfault 0 collisions 0
zones 7.7M protection 0 *NetIF[lo0]
ptbl 2.9M demand 0 Scheduler
fs ctl 9.8M cw 0 runq 0
fs data 105.9M steal 0 swapq 0
delwri 0 onswap 0 switch 65
free 350.5M oncache 0 *Large page stats
userdata 19.2M onfile 0 *Interrupts
pgallocs 0 freed 0 *PathName Cache
Node[0] unmodswap 0 *Heap
Totalmem505.1M unmodfile 0 *EfsAct
freemem 350.5M iclean 0 *XfsAct
64k page 1.6K *TLB Actions *Getblk
256k pages 0 Video *Vnodes
exit 1MB pages 0 vidioctl 0
|
Performance Co-Pilot (PCP) provides a suite of tools that co-operate to deliver distributed, integrated performance-monitoring and performance-management services across a spectrum of performance domains, as shown in Figure 8-3.
For more information about Performance Co-Pilot, see its man page, pcp(1M).