Scripts Development

IxChariot Scripts Development
and Editing Guide

7.30 SP3, February 2016
Copyright and Disclaimer
Copyright 2016 Ixia. All rights reserved.
This publication may not be copied, in whole or in part, without Ixia's consent.
RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the U.S. Government
is subject to the restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data
and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19.
Ixia, the Ixia logo, and all Ixia brand names and product names in this document are either trade-
marks or registered trademarks of Ixia in the United States and/or other countries. All other
trademarks belong to their respective owners.
The information herein is furnished for informational use only, is subject to change by Ixia
without notice, and should not be construed as a commitment by Ixia. Ixia assumes no respons-
ibility or liability for any errors or inaccuracies contained in this publication.
Ixia Worldwide Headquarters

Web site: www.ixiacom.com
26601 W. Agoura Rd.
General: info@ixiacom.com
Calabasas, CA 91302
Investor Relations: ir@ixi-
USA
acom.com
Corporate +1 877 FOR IXIA (877 367
Headquarters 4942) Training: train-
ing@ixiacom.com
+1 818 871 1800 (Inter-
Support: sup-
national)
port@ixiacom.com
(FAX) +1 818 871 1805
+1 818 595 2599
sales@ixiacom.com
Ixia Europe Limited
Part 2nd floor,
Clarion House, Norreys Drive Support: support-emea@ixi-
EMEA Maidenhead, UK SL6 4FL acom.com
+44 (1628) 408750 +40 21 301 5699
FAX +44 (1628) 639916
salesemea@ixiacom.com
Support: support-asiapac@ixi-
Ixia Pte Ltd
Asia Pacific acom.com
210 Middle Road
+91 80 4939 6410
- ii -
#08-01 IOI Plaza
Singapore 188994
Ixia KK
Nishi-Shinjuku Mitsui Bldg

11F Support: support-japan@ixi-
Japan 6-24-1, Nishi-Shinjuku, Shin- acom.com
juku-ku +81 3 5326 1980
Tokyo 160-0023
Japan
Ixia Technologies Pvt Ltd
Tower 1, 7th Floor, UMIYA

Business Bay
Cessna Business Park
Survey No. 10/1A, 10/2, 11 &

13/2 Support: support-indi-
India Outer Ring Road, Varthur a@ixiacom.com
Hobli +91 80 4939 6410
Kadubeesanahalli Village
Bangalore East Taluk
Bangalore-560 037,
Karnataka, India
+91 80 42862600
Support: support-chin-
Ixia Technologies (Shanghai)
a@ixiacom.com
Company Ltd
400 898 0598 (Greater China
China Unit 3, 11th Floor, Raffles
Region)
City, Beijing
+86 10 5732 3932 (Hong
Beijing, 100007 P.R.C.
Kong)
For viewing the FAQs related to the product, go to Ixia Technical Support Online:
http://www.ixiacom.com/support-services/contact-support
- iii -
IxChariot Scripts Development and Editing Guide
Contents
Chapter 1: About This Guide 1

Purpose 1
Manual Content 1
Related Documentation 2
Technical Support 2
Chapter 2: Application Scripts Overview 3
How IxChariot Uses the Scripts 3
Synchronized Pair Testing 3
Chapter 3: Application Script Structure 4
Nonstreaming Scripts 4
Required Commands 4
Streaming Scripts 5
Maximum Number of Commands 6
Chapter 4: Editing and Creating Scripts with the Script Editor 7
Accessing the Script Editor 8
Editing the Script Used by a Single Pair 9
Editing the Script Used by Multiple Pairs 10
Saving Script Files 11
Editing Parameters and Variables 12
Editing a Parameter of a Script Command 13
Editing a Script Variable 15
Adding, Moving, and Deleting Commands 17
Moving and Deleting Commands 17
Inserting Commands 17
Command Insertion Example 17
Adding a New Script 19
- iv -
Procedure for Creating a New Script 19

For More Information 20
Short Versus Long Connections 20
Disabling the Nagle Algorithm 21
Selecting RFC768 UDP 22
Disabling the UDP Checksum 23
Setting the Transmit MSS Option 25
Script Editor User Interface Reference 26
The File Menu 27
The Edit Menu 28
The Insert Menu 29
Script Editor Toolbar 31
Shortcut Keys for the Script Editor 32
Chapter 5: Script Command Reference 33
Communication Commands 34
CONNECT_INITIATE 34
Command Description 34
Parameters 34
Usage Notes for CONNECT and DISCONNECT 34
CONNECT_ACCEPT 35
Parameters 35
Usage Notes 35
SEND 35
Parameters 36
Usage Notes for SEND and RECEIVE 36
RECEIVE 36
-v-
Parameters 36
Usage Notes 36
CONFIRM_REQUEST 37
Parameters 37
Usage Notes for CONFIRM Commands 37
CONFIRM_ACKNOWLEDGE 37
Parameters 37
Usage Notes 37
DISCONNECT 37
Parameters 37
Usage Notes 37
Application Commands 39
SLEEP 39
Parameters 39
Usage Notes 39
OPTION 39
Parameters 40
Notes 40
RTP_PAYLOAD_TYPE 40
Parameters 40
Notes 40
- vi -
Supported RTP Payload Types 40

Program Control Commands 42
LOOP 42
Parameters 42
Usage Notes for LOOP and END_LOOP 42
END_LOOP 42
Parameters 42
Usage Notes 42
START_TIMER 43
Parameters 43
Usage Notes for the START_TIMER, END_TIMER, and INCREMENT_
TRANSACTION Commands 43
END_TIMER 43
Parameters 43
Usage Notes 43
INCREMENT_TRANSACTION 43
Parameters 44
Usage Notes 44
WAIT_EVENT 44
Parameters 44
Usage Notes for WAIT_EVENT and SIGNAL_EVENT 44
SIGNAL_EVENT 44
- vii -
Parameters 45
Usage Notes 45
Chapter 6: Configuring IxChariot Script Variables 46
Script Variable Overview 47
Script Variable Rules 47
Default Value Versus Current Value 47
Setting Source and Destination Ports 48
Using AUTO 48
Using Specific Port Numbers 48
Port Number Categories 48
Setting the SEND Data Rate 50
Selectable Data Rates 50
Send-Data-Rate Guidelines 50
Setting the SEND Data Type 52
Setting the SEND/RECEIVE Buffer Size 53
Types of Buffers in IxChariot Scripts 53
SEND and RECEIVE Buffers 53
Using a Constant Value for Buffer Size 53
Using Random Buffer Sizes for the SEND Command 53
Randomizing Buffer Sizes 54
Setting SLEEP Times 55
Standard SLEEP Variables 55
SLEEP Variable Durations 55
Guidelines for SLEEP Variables 55
Random Distributions 57
Uniform Distribution 57
Normal Distribution 57
Poisson Distribution 58
- viii -
Exponential Distribution 58
Chapter 7: Providing Script Payload 60
SEND Command Payload Options 61
ZEROS and NOCOMPRESS Payload 62
Using Calgary Corpus Compression Files 63
List of Calgary Corpus Files 63
Using Your Own .cmp Files 64
Creating Your Own .cmp Files 64
HTTP GET Example 64
User01.cmp 64
User02.cmp 64
Test Configuration 64
Specifying Embedded Payload Data 66
Specifying External Payload Files 68
External Payload File Overview 68
Selecting an External Payload File 68
Using Embedded Versus Reference Payload Data 69
Referenced Payload File Considerations 70
Saving a Script with Embedded or Referenced Payload Data 70
Saving a Test with External Payload 70
Exporting Tests with External Payload to Older Versions 71
Chapter 8: IxChariot Application Groups 72
Synchronized Pair Testing 73
Introduction to Synchronized Pair Testing 74
Types of Pairs Supported 75
How Synchronization is Achieved 76
Application Groups 76
Synchronization Commands 76
- ix -
Events 76
Application Groups Delivered with IxChariot 77
How Wait Times Are Recorded in Timing Records 78
The Type Parameter 78
Wait Times in Nonstreaming Scripts 78
Wait Times in Streaming Scripts 78
Creating and Running Synchronized Pair Tests 80
Creating a Test from an Application Group 81
Importing an Application Group 81
Creating and Saving the Test 81
Application Group Validation 82
Error Conditions in Application Group Tests 83
Creating and Managing Application Groups 84
The Application Group Submenu 85
Creating an Application Group 86
Editing an Application Group 88
Adding Events to an Application Group 89
Deleting an Application Group 90
Copying and Pasting an Application Group 91
Renaming an Application Group 92
Adding Pairs to an Existing Application Group 93
Removing Pairs from an Application Group 94
Replacing Host Addresses in an Application Group 95
Validating an Application Group 96
Exporting an Application Group to a File 97
Importing an Application Group from a File 98
Adding Synchronization Commands to Scripts 99
Test Requirements 100
-x-
Rules for Writing Scripts for Application Groups 101

Editing Scripts to Add Synchronization Commands 102
Synchronization Commands Example 103
Creating Synchronization Tests for VoIP Pairs 105
Location of Wait and Signal Commands in Streaming Scripts 106
Creating a Synchronized Test for VoIP Pairs 107
Appendix A: Mapping Communication Commands to APIs 109
Mapping of Script Commands for Sockets 110
Notes for Table A-1 110
Sockets Datagram send_buffer_size 110
Sockets Datagram receive_buffer_size 111
Mapping of Script Commands for TLI 112
Notes for Table A-2 112
TLI Datagram send_buffer_size 112
TLI Datagram receive_buffer_size 112
Appendix B: Default Buffer Sizes for IxChariot Scripts 114
Index 115
- xi -
Chapter 1: About This Guide
The information in this section is provided to help you navigate this manual and make better use of its content.
A list of related documentation is also included.
Topics:
l Purpose
l Manual Content
l Related Documentation
l Technical Support
Purpose
This manual provides a complete reference for IxChariot users who need to:
l Create custom application scripts.
l Modify application scripts.
l Create and use application groups.
Manual Content
This manual contains the following sections:
Name Description
About This Provides information on this manual, including its purpose, content, and related doc-
Guide umentation. Also explains how to contact technical support.
Chapter 2,
Application
Provides a brief overview of IxChariot application scripts and application groups.
Scripts Over-
view
Chapter 3,
Describes the basic structure of IxChariot scripts and describes the commands that are
Application
required in all scripts.
Script Structure
Chapter 4, Edit- Provides instructions for using the IxChariot Script Editor, including procedures for editing
ing and Creat- parameters and variables, creating new scripts from script templates, and saving new and
ing Scripts with modified script files. Also includes a reference section for the Script Editor menus and tool-
the Script Editor bar.
Chapter 5,
Script Com-
Provides a reference for all script commands.
mand Refer-
ence
Provides instructions for configuring IxChariot parameters and variables, including pro-
Chapter 6, Con-
cedures for setting source and destination port addresses, setting SLEEP times, setting the
figuring
SEND data rate, setting the SEND data type, and setting the SEND/RECEIVE buffer size.
IxChariot Script
Also includes a description of the four random distributions that can be used for SLEEP
Variables
times and buffer sizes.
Chapter 7, Describes the available options for providing the payload that is transmitted from one end-
Providing Script point to another by IxChariot scripts.
-1-
Payload
Chapter 8,
Provides a complete description of IxChariot application groups: what they are, how they
IxChariot Applic-
are used, and how to create them.
ation Groups
Appendix A,
Mapping Com-
Describes the mapping of IxChariot communication commands to the APIs on the endpoint
munication
computers.
Commands to
APIs
Appendix B,
Default Buffer
Lists the default buffer sizes for the protocols and platforms supported by the IxChariot Per-
Sizes for
formance Endpoint software.
IxChariot
Scripts
Related Documentation
The IxChariot documentation suite includes the following manuals:
l Getting Started with IxChariot
l IxChariot User Guide
l IxChariot Runtime User Guide
l IxChariot Performance Endpoints
l IxChariot Scripts and Streams Reference Guide
l IxChariot Scripts Development Guide (this guide)
l IxChariot API Reference
The following additional manuals are provided for customers who are using Ixia chassis in their testing:
l Stack Manager User Guide
l Stack Manager API Reference
The IxChariot manuals are provided in hardcopy and PDF format.
IxChariot also provides comprehensive context-sensitive online help.
Technical Support
You can obtain technical support for any Ixia product by contacting Ixia Technical Support by any of the meth-
ods mentioned on the inside cover of this manual. Technical support from Ixia's corporate headquarters is avail-
able Monday through Friday from 6 a.m. to 6 p.m., Pacific Standard Time (excluding American holidays).
Technical support from Ixia's EMEA and India locations is available Monday through Friday, 8 a.m. to 5 p.m.
local time (excluding local holidays).
-2-
Chapter 2: Application Scripts Overview

IxChariot application scripts are the key to measuring network performance. They model the traffic patterns of
the applications you use between computers in a network. IxChariot uses application scripts to make the same
API calls to the network protocol stacks that real applications make, causing the protocol stacks to perform the
same work involved in sending and receiving data that your applications perform every day.
Scripts consist of commands, such as SEND and RECEIVE, and script variables, such as the Send Buffer Size,
which produce different data flows on the network. You can alter the parameters and variables that control
script commands, and thus customize the scripts you use in testing and monitoring.
IxChariot application scripts are generally independent of the network protocol. This means the same script can
be used with any network protocol supported by the Performance Endpoints you are using.
There are two broad categories of scripts:
l Streaming scripts require a datagram (connectionless) protocol, such as IPX, RTP, or UDP.
l Nonstreaming scripts require a connection-oriented protocol, such as TCP or SPX.
Both types of scripts are described in this manual.
How IxChariot Uses the Scripts

Application scripts are stored on the computer where you configure tests (that is, at the IxChariot Console).
When you initiate execution of a test, IxChariot delivers the scripts to the endpoints. The scripts execute their
instructions on the endpoint computers.
When you install IxChariot, the installer places a library of application scripts in subdirectory of the installation
folder. For example, if you installed IxChariot in D:\Program Files\Ixia\IxChariot, the script files are located in
D:\Program Files\Ixia\IxChariot\Scripts. The scripts are organized in libraries, such as Internet Scripts, Business
Scripts, and Streaming Scripts. Refer to the IxChariot Streams and Scripts Libraries Reference guide for a
description of all the stream files and scripts delivered with IxChariot.
If you decide to store the script files on a different drive or in a different directory, you should update the Where
to read script files field on the Directories tab of the Change User Settings notebook. Refer to the IxChariot User
Guide for more information.
The user interface in IxChariot offers dialog boxes for modifying the variables in any script. In addition, you can
modify existing script files or create your own script files from scratch. The Script Editor, included with IxChariot,
reads and writes binary script files in the IxChariot format.
If you would like to create custom scripts, you can also use IxProfile to trace an application's WinSock calls and
generate a script from those calls. You can also use IxProfile to create an IxChariot script from a line trace file
that was generated by a network protocol analyzer, such as Ethereal. You can then use the IxChariot Script
Editor to modify the scripts that you generate in IxProfile. Refer to the IxProfile User Guide for more information.
Synchronized Pair Testing

IxChariot tests can emulate applications that employ multiple connections. For example, FTP operations require
two concurrent connections: one for control (port 21), the other for data transmission (port 20).
Modeling such an application requires a set of scripts that communicate among themselves such that one script
can pause and resume its execution based on the actions of another script. IxChariot application groups
provide this capability. They enable synchronized pair testing: tests that use multiple, interacting scripts.
The IxChariot script library includes several application groups that you can use unchanged, or that you can
use to create your own application groups. Chapter 8, IxChariot Application Groups, presents a detailed descrip-
tion of application groups: what they are, how they work, and how to create and modify them.
-3-
Chapter 3: Application Script Structure

This chapter describes the basic structure that all IxChariot scripts use, both streaming and nonstreaming.
Topics in this chapter:
l Nonstreaming Scripts
l Streaming Scripts
l Maximum Number of Commands
Nonstreaming Scripts
Nonstreaming scripts emulate the traffic of applications that require two-way communication. A database query
script, for example, requires a request/response transaction between a client and a server. Figure 3-1 shows an
example of a basic ("empty") nonstreaming script.
Figure 3-1. Basic Nonstreaming Script
As shown in this example, every script comprises the statements for both Endpoint1 and Endpoint2.
Required Commands
Every nonstreaming IxChariot script includes the following commands for Endpoint1:
...
LOOP
count = number_of_timing_records (50)
START_TIMER
LOOP
count = transactions_per_record (100)
...
INCREMENT_TRANSACTION
END_LOOP
END_TIMER
...
END_LOOP
...
When you use the IxChariot Script Editor to create a new "empty" script, it provides these seven commands as
the basic framework to which you will add commands and parameters to model application traffic. Table 3-1
provides a brief description of these commands. (Also see Chapter 5, Script Command Reference, for a more
detailed explanation of each command.)
-4-
Table 3-1. Required Commands in a Nonstreaming Script

Command Description
Starts the outer loop of the script. The number of executions of the outer loop is defined by
LOOP the "number_of_timing_records" variable. Each pass through the outer loop generates one
timing record.
START_TIMER Marks the beginning of a checkpoint and starts a timer that tracks the test run time.
Starts the inner loop of the script. The number of executions of the inner loop is defined by
LOOP the "transactions_per_record" variable. Each pass through the inner loop generates one
transaction for the current record.
INCREMENT_
TRANSACTION Counts the number of transactions in the inner loop.
END_LOOP Ends the inner loop.
END_TIMER Marks the end of a checkpoint and causes a timing record to be generated.
END_LOOP Ends the outer loop.
Streaming Scripts
Streaming scripts emulate applications that require a unidirectional flow of data at a specified data rate. They
use a datagram (connectionless) protocol to stream data packets from Endpoint1 to Endpoint2. Figure 3-2
shows an example of the IxChariot streaming script template.
Figure 3-2. Basic Streaming Script
As is the case with nonstreaming scripts, every streaming script comprises the statements for both Endpoint1
and Endpoint2.
When you use the IxChariot Script Editor to create a new streaming script, it provides the commands described
in Table 3-2.
Table 3-2. Required Commands in a Streaming Script
Command Description
RTP_
Specifies the payload type for scripts that use RTP as the transport protocol. The default type
PAYLOAD_
is H261. (Refer to RTP_PAYLOAD_TYPE for a list of the payload types.)
TYPE
-5-
SLEEP Specifies the initial delay, in milliseconds.

CONNECT_
Initiates a connection from Endpoint1 to Endpoint2.
INITIATE
CONNECT_
Endpoint2 accepts the connection initiated by Endpoint1.
ACCEPT
Starts the single loop of the script. The loop uses the "count" variable to determine the num-
LOOP
ber of interactions. Each pass through the loop generates one timing record.
START_
Marks the beginning of a checkpoint and starts a timer that tracks the test run time.
TIMER
SEND Endpoint1 executes this command to send data (a record or a file) to Endpoint2.
RECEIVE Endpoint2 executes this command to receive the data that was sent by Endpoint1.
END_LOOP Ends the loop.
DISCONNECT
Ends the connection established by the CONNECT_INITIATE command.
Because the streaming script template contains all of the commands required for a valid streaming script, you
cannot modify the structure of the script. However, you can modify the variables in the script and you can insert
SLEEP and OPTION commands into the script.
Maximum Number of Commands

The following rules apply to all scripts:
l A maximum of 1,300 command lines are permitted per script
l A maximum of 1,000 SEND and RECEIVE command lines are permitted per script.
If you are developing a script that exceeds either of these maximums, you will need to reorganize the trans-
actions into multiple scripts.
-6-
Chapter 4: Editing and Creating Scripts

with the Script Editor
This chapter describes the IxChariot Script Editor. The Script Editor lets you create new application scripts and
modify existing scripts to emulate the flows of complex applications.
l Accessing the Script Editor
l Saving Script Files
l Editing Parameters and Variables
l Adding a New Script
l Disabling the Nagle Algorithm
l Selecting RFC768 UDP
l Disabling the UDP Checksum
l Setting the Transmit MSS Option
l Script Editor User Interface Reference
-7-
Accessing the Script Editor

You access the IxChariot Script Editor to accomplish any of the following tasks:
l To make changes to a script that will apply to a single pair. Refer to Editing the Script Used by a Single
Pair for instructions.
l To make changes to a script that will apply to multiple pairs. Refer to Editing the Script Used by Multiple
Pairs for instructions.
l To create a new script based on a script template. Refer to Adding a New Scriptfor instructions.
Figure 4-1 shows an example of the Script Editor window.
Figure 4-1. Script Editor
-8-
Editing the Script Used by a Single Pair
To edit a script used by a single pair, follow these steps:

1. Select the pair in the Test Setup window.
2. Select Edit ... from the Edit menu.
IxChariot opens the Edit an Endpoint Pair dialog.
3. Click the Edit This Script button.
IxChariot loads the selected script into the Script Editor, making it available for modification.
4. Make the desired changes.
The topics in this chapter provide detailed information about modifying scripts.
5. Select Save to Pair from the File menu.
IxChariot saves the modified script with the pair.
6. Select Exit from the File menu.
IxChariot closes the Script Editor.
-9-
Editing the Script Used by Multiple Pairs
You can edit a script that is used by multiple pairs if those pairs use an identical script. Not only must it be the
same script (such as Throughput.scr), but the scripts used in the pairs must be identical in all aspects: they must
have the same steps, the same variables, and the same values applied to the variables.
To edit a script used by multiple pairs, follow these steps:
1. Select the pairs in the Test Setup window.
2. Select Edit ... from the Edit menu.
IxChariot opens the Edit Multiple Endpoint Pairs dialog. If the scripts used by the selected pairs are
identical in all aspects, IxChariot enables the Edit This Script button. Otherwise, the button is disabled.
3. Click the Edit This Script button.
IxChariot loads the selected script into the Script Editor, making it available for modification.
4. Make the desired changes.
The topics in this chapter provide detailed information about modifying scripts.
5. Select Save to Pair from the File menu.
IxChariot saves a copy of the modified script with each of the pairs.
6. Select Exit from the File menu.
IxChariot closes the Script Editor.
- 10 -
Saving Script Files

When you edit an existing script or create a new script, you need to save your changes to disk. Your options for
saving a script to disk differ slightly, depending on how you accessed the Script Editor. Table 4-1 describes the
commands for saving script files.
Table 4-1. Commands for Saving Scripts
If you accessed the Script Editor by... then you will save your script changes by...
Choosing one of the following:
selecting Edit Scripts... from the Tools l Selecting Save from the File menu to save your changes
menu, to the script file.
l Selecting Save As and assigning the script a new name
Choosing one of the following:

l Selecting Save to Pair from the File menu to save your
modified IxChariot script file with the selected pair. The
clicking Edit This Script in the Add an End-
changes you make to the script will apply only to the
point Pair, Add a Multicast Group, Edit an
script used by the selected pair.
Endpoint Pair, or Edit Multiple Endpoint
Pairs dialog box, l Selecting Save to File from the File menu to save the cur-
rent IxChariot script file to disk. You can save the script
using the original name, or save it using a different name.
In either case, your changes are permanent.
Each time you return to the IxChariot Test window from the Script Editor, any unsaved changes you made to a
script are discarded.
If you have modified the current script and not saved your changes, a message box asks if you want to save
your changes to the current script.
- 11 -
Editing Parameters and Variables

One aspect of configuring an IxChariot test is to edit the scripts selected for the test. The most common editing
task is to modify the contents of the script variables. The basic script editing tasks are described in the following
topics:
l Editing a Parameter of a Script Command
l Editing a Script Variable
- 12 -
Editing a Parameter of a Script Command
In the lower part of the Script Editor window, variable elements of each parameter in a script are shown. Most
script commands have parameters that you can change to better emulate your applications and the types of
data they send on your network.
To edit a parameter:
1. Select the desired parameter in the upper portion of the Script Editor.
2. Select Edit Parameter from the Edit menu.
The Script Editor opens the Edit Parameter dialog, as shown in Figure 4-2.
Figure 4-2. Edit Parameter Dialog
3. Make any desired changes.

4. Click OK.
Table 4-2 describes the fields in the Edit Parameter dialog.
Table 4-2. Fields in the Edit Parameter Dialog
Field Description
The parameter currently being edited. All the parameters for the command are available in the
Parameter
list. The Constant and Variable buttons let you define the type of parameter you want to edit. If
either choice is not applicable to the parameter, that button is grayed out.
Constant A unique value that you assign to a single instance of a variable within a script; enter the new
- 13 -
value in the field. When you click Constant, all fields are grayed out because the rules governing
default instances of this variable do not apply.
A value that will be changed automatically for all instances of this parameter within your script.
Variable When you click Variable, all fields are enabled because the rules governing default instances of
this variable apply to your choices.
Variable The variable you want to edit. A list of appropriate variables previously defined in the script is
Name available from the list. See Editing a Script Variable for more information on the variable fields.
The value assigned to the variable. The available choices vary according to the parameter; for
example, if you chose the Sleep Time parameter, the available choices are Constant Value and
Current Uniform, Normal, Poisson, and Exponential Distribution. Do not use commas when entering val-
Value ues in this field.
Click Reset to reset the value in the Current value field to the value showing in the Default value
field the last time you exited the Edit Variable dialog box for this variable.
Instructs the endpoint to use the default appropriate for the protocol being used and the API of the
Default platform in which it is operating. This field lets you specify the initial value for the variable, when
Value the script is loaded from a file into a test.
Refer to Default Value Versus Current Value for more information.
Comment A brief explanation of what the parameter instructs the endpoint to do.
Variable A description of the variable and how it operates in a script. You can customize the help text by
help entering information in this field.
- 14 -
Editing a Script Variable
The Edit Variable dialog box is a limited version of the Edit Parameter dialog box; the two are very similar. Vari-
ables are used in scripts to enable command parameters to be changed globally within a script. They can be
used to control loops, define port numbers, specify the data type for a send, and so forth.
To edit a script variable:
1. Select the variable from the Variable Name list in the lower area of the Script Editor window.
2. Select Edit Variable from the Edit menu.
The Script Editor opens the Edit Variable dialog, as shown in Figure 4-3.
Figure 4-3. Edit Variable Dialog
3. Make any desired changes.

Click Reset if you want to set the Current Value equal to the Default Value. Refer to Default Value
Versus Current Value for more information.
4. Click OK.
Table 4-3 describes the fields in the Edit Parameter dialog.
Table 4-3. Fields in the Edit Variable Dialog
Field Description
Variable A name for the variable that must be unique within the script, and cannot contain blanks; under-
Name scores are appropriate, however.
Current The type of value to be selected. The available choices vary according to the parameter; for
- 15 -
example, if you chose the Sleep Time parameter, the available choices are Constant Value and
Uniform, Normal, Poisson, and Exponential Distribution. Do not use commas when entering val-
ues in this field.
The type of variable used for the SLEEP command allows five values: Constant Value, Uniform
Distribution, Normal, Poisson, and Exponential. For a Constant Value, one field is presented for
Value the value. For a distribution, two fields let you enter the upper and lower distribution range. All val-
ues are in milliseconds. See "Setting Sleep Times" in the "Rules for Scripts" section of the Applic-
ation Scripts guide for more information and pictures of the distributions.
Click Reset to reset the value in the Current value field to the value showing in the Default value
field the last time you exited the Edit Variable dialog box for this variable.
Refer to Default Value Versus Current Value for more information.
Lets you specify the initial value for the variable, when the script is loaded from a file into a test.
Accepts numbers to 9 digits. On some variable types, such as the buffer size on SEND and
Default RECEIVE, you can use the terms "DEFAULT" or "AUTO." The DEFAULT value depends on the net-
Value work protocol and the endpoints you are using. AUTO, when entered for the "source_port" or "des-
tination_port" variables, specifies that Endpoint 1 should choose the port number dynamically. Do
not use commas when entering values in this field.
Comment
A brief explanation of what the variable instructs the endpoint to do.
Variable A description of the variable and how it operates in a script. You can customize the help text by
Help entering information in this field.
- 16 -
Adding, Moving, and Deleting Commands

The Script Editor provide tools for adding, moving, and removing commands in a script.
Moving and Deleting Commands

The Edit menu provides the following options for rearranging the location of commands within a script:
l Edit > Delete
Deletes the selected command and variable from a script. This option is not available if the deletion
would result in an invalid script.
l Edit > Move Up, and Edit > Move Down
Moves a variable up or down in the sequence of commands in a script. To keep the script valid, this
menu item is only available when moving the highlighted variable in a valid scripting choice. In some
cases, the Move Up/Down function may cause the highlighted variable to move to the next valid place in
the script or may cause other variables to move.
l Edit > Swap Sides
Moves a command to the opposite endpoint or reverses a command pair. For example, if you highlight
SEND/RECEIVE and use the Swap sides functionality, the command pair is now RECEIVE/SEND. This
menu option is valid for only certain commands.
Inserting Commands
To insert a script command:
1. Choose an insertion point by selecting a command (or group of commands):
l Choose a block of commands as the insertion point if you are inserting either of the following
commands: Connect...or Loop...
In this case, the commands that you insert will surround the insertion point. Refer to Command
Insertion Example for more information.
l For all other insertions, choose a single command as the insertion point. The command that you
insert will be placed after the insertion point.
2. Select a command from the Insert menu.
The Script Editor opens the Edit Parameter dialog.
3. Modify the command parameter as desired.
Refer to Editing a Parameter of a Script Command for more information.
4. Click OK.
The Script Editor inserts the new command(s), either after or surrounding the original insertion point.
When you insert a command in one endpoint that has a corollary in the other endpoint, the Script Editor auto-
matically adds the corresponding command. For example, if you add a SEND command to Endpoint1, the
Script Editor automatically inserts the corresponding RECEIVE command to Endpoint2.
Command Insertion Example

When you insert a command into a script, it is important that you select the correct insertion point. This is espe-
cially true for the CONNECT and LOOP commands because they each have a terminating command
(DISCONNECT and END_LOOP). Therefore, the insertion point must be the entire block of commands that will
be contained within the connection or the loop.
Figure 4-4 shows an example of adding a CONNECT command to the script, using the Insert > Connect...
menu option. Note that:
- 17 -
l The insertion point is a block of commands: rows 6, 7, and 8 in this example.

l Once the command has been inserted, the original insertion point is now enclosed within the
CONNECT/DISCONNECT commands.
Figure 4-4. Inserting CONNECT/DISCONNECT Commands
- 18 -
Adding a New Script

You can create a new script based on script templates.
Procedure for Creating a New Script

To create a new script from a template:
1. Select Edit Scripts... from the Tools menu.
IxChariot opens the Script Editor, displaying the default script template. (The Basic Long Connection
Template is the default).
2. From within the Script Editor, select New from the File menu.
3. Select one of the following script templates:
l Basic Long Connection Template
A version of the Credit Check transaction that uses a long connection (that is, it makes only one
connection for the entire transaction). This is a quick transaction that emulates a series of credit
approvals. A record is sent from Endpoint 1. Endpoint 2 receives the record and sends back a
confirmation. Use this template as a starting point for most scripts, or if you are unsure which tem-
plate to use. (Refer to Short Versus Long Connections for more information.)
l Basic Short Connection Template
A version of the Credit Check transaction that uses short connections (that is, it reestablishes a
connection for each transaction). This is a quick transaction that emulates a series of credit
approvals. A record is sent from Endpoint 1. Endpoint 2 receives the record and sends back a
confirmation. Use this template to create a script that initiates a connection for each transaction.
l Empty
Contains the minimum parameters required in a script and does not contain any SEND or
RECEIVE commands. Use this template as a starting point to create a script from scratch.
l Streaming
Contains the commands necessary for a streaming script. Because the script contains all of the
commands required for a valid streaming script, you cannot modify the structure of the script.
However, you can insert SLEEP and OPTION commands into the script, and you can modify the
variables in the script. Use this template for all streaming scripts.
4. Click OK.
The Script Editor shows the script template you selected.
5. Enter a brief description (up to 40 characters) of the script in the Application Script Name field.
This script name is required.
6. Modify the parameters and variables, as required.
When editing script parameters, you can change their names and the variables included in each para-
meter. Refer to Editing a Parameter of a Script Command for detailed information.
When editing script variables, you can change their names, their current and default values, and their
comments. Refer to Editing a Script Variable for detailed information.
7. Use the Script Editor menu options or toolbar to insert, move, or deleted commands.
Refer to Adding, Moving, and Deleting Commands for detailed information.
Refer to Script Editor User Interface Reference for a description of all of the Script Editor menus and tool-
bars.
8. Save the new script, using the Save option from the File menu.
The Script Editor save the file using a .scr file extension.
- 19 -
For More Information

For a full description of the script commands and their parameters, as well as the rules governing the creation of
valid scripts, refer to Chapter 5, Script Command Reference.
Refer to HTTP GET Example for an example of a user-defined script.
Short Versus Long Connections

Many IxChariot scripts come in two variations: long connection and short connection.
l In scripts identified as long connections, a single connection is used for the entire test script, no matter
how many transactions are run. The time it takes to start and stop the connections is not included in the
timings.
l In those identified as short connections, a new connection is started for each transaction.
You can distinguish one from another by the last character in the file name: long connection script names end
with an "L," while short connection script names end with an "S."
All network protocols have overhead associated with connection setup and take-down. The performance dif-
ference between short and long connections can be dramatic. How do you decide which to run? Here are sev-
eral guidelines that make the decision simple.
l If you are trying to emulate a particular application, use the same connection type that the application
uses.
l If you are trying to test a network backbone or the equipment that supports one, use long connections.
Because the test endpoints do not have to go through the overhead of starting and ending the con-
nection, each endpoint pair can create considerably more traffic.
l If you are trying to test a network protocol stack, run a mix of long- and short-connection scripts.
l If you are running large tests of at least 500 endpoint pairs, do not use short-connection scripts. They are
too taxing for most networks.
- 20 -
Disabling the Nagle Algorithm

To better emulate certain types of TCP applications, IxChariot lets you disable the Nagle algorithm, which con-
trols congestion on TCP/IP networks. Defined in RFC 896, the Nagle algorithm was designed to reduce the
wasted bandwidth associated with tiny chunks of data (John Nagle refers to them as tinygrams), whose over-
head-to-payload ratio can be as high as 40-1. Nagle specifies the following:
l The sending computer will buffer all user data until an acknowledgment is received.
l The sending computer can begin sending data, combined into larger packets, when all sent data has
been acknowledged, or as soon as it has a full maximum segment-size (MSS) packet of data to send.
l The overall effect is that fewer, larger packets are sent.
Nagle is enabled by default in TCP/IP stacks. It greatly increases throughput. In most cases, it is a bad idea to
disable the Nagle algorithm. However, some TCP applications, such as X-Server applications or TCP applic-
ations that send data in real time, have to disable it in order to send small amounts of data at a constant rate.
Plus, as Nagle himself admits, the Delayed ACK implementations on many networks may work badly with the
Nagle algorithm. The Delayed ACK specifies that the sending computer will not send any more data until it has
some more data on which the small ACK packets can be piggybacked. If the Delayed ACK is implemented, the
receiver is required to wait for a fixed maximum amount of time, as much as 200 ms on some networks. In a few
cases, such as sequences of "SEND, SEND, WAIT-FOR_REPLY" where both SENDs contain small amounts of
data, the connection may be stalled for one ACK delay timer plus one round-trip time.
Therefore, some applications disable the Nagle algorithm. To emulate them, you can disable it for IxChariot
tests in the Script Editor. Just do the following:
1. On the Insert menu in the Script Editor, click Options at Endpoint 1 or Options at Endpoint 2.
2. The Edit Parameter dialog box is shown, with the parameter Nagle Algorithm (TCP Only) selected.
3. In the Current Value list, click Disabled.
Another case in which you may want to disable Nagle is in TCP tests that use random buffer sizes. A few TCP
applications may not buffer smaller packets and send them out in larger chunks, but instead send data as
quickly as it becomes available, in packets of varying sizes. With random buffer sizes, your scripts can real-
istically emulate these applications. But if you do not also disable Nagle when you test with random buffer
sizes, your tests will not mean much. That is because Nagle requires the sending computer to use the MSS for
the packets it sends, overriding the BUFFER_SIZE you have selected. See Setting the SEND/RECEIVE Buffer
Size for more information.
Of course, when you disable Nagle, you should expect to see substantially reduced throughput. Do not disable
it if you are doing performance testing.
Note:On Linux, disabling Nagle will not produce the effect described above. If your sockets program (in this
case, the endpoint) does many SENDs of small sizes, do not expect to see each of those SEND requests in its
own packet. Linux will combine them into larger packets.
The MVS operating system does not support the disabling of the Nagle algorithm.
- 21 -
Selecting RFC768 UDP

When you select UDP as the network protocol for a streaming script, IxChariot automatically selects its pro-
prietary version of the UDP protocol for the test. This UDP implementation incorporates a custom header within
the data field, which enables the collection of test statistics.
You can, however, modify the script to use the UDP implementation that is compliant with RFC768. To do so:
1. Open the script in the Script Editor
2. Select UDP compliant with RFC768 option ... from the Insert menu.
The Script Editor inserts the OPTION command a the top of the script.
3. Save the script.
Using RFC768 UDP limits the number of statistics that the test can measure. However, it does guarantee that
your test will transmit unaltered payload.
- 22 -
Disabling the UDP Checksum

The UDP standard stated in RFC 768 permits an application to turn off the generation of the checksum field of
the UDP header, which by default is enabled. The UDP checksum is distinct from the checksum field of the IP
header, but is used for the same purpose, to provide a check of data integrity.
IxChariot now allows you to disable the UDP checksum. This option lets you more closely emulate certain mul-
timedia streaming traffic, which may disable UDP checksums.
The run-time cost of calculating and checking UDP checksums increases with datagram size. However, the pro-
portionate cost of building a header, including the checksum, increases as datagram size decreases because
the payload-to-header ratio is lower. Calculating a checksum on the sending side and checking it on the receiv-
ing side take time and resources, although some have argued that the impact on network performance is usu-
ally insignificant. Disable the checksum to measure that impact.
To disable the UDP checksum for E1 or E2, edit the application script you are running between the endpoints.
Click UDP Checksum at Endpoint 1 or Endpoint 2 on the Insert menu. A new variable, udp_checksum_e1=Di-
isabled or udp_checksum_e2=Disabled, is added to the script under the OPTION command. You can double-
click the new variable to reenable it.
Note:For a protocol other than UDP, this option will have no effect, although no warning message will be
issued. If this option is specified for an endpoint whose communications stack does not support the disabling
of UDP checksums, you will see an error message, unless you are running VoIP endpoint pairs. The UDP
checksum is disabled by default for all voice over IP pairs, as long as the operating system allows it. For VoIP
pairs a "best effort" is made to disable the UDP checksum, but failure to do so is not treated as an error.
If the Transport layer does not compute a UDP checksum, it sets the field to zero. Receivers do not validate a
checksum of zero.
Disabling the UDP checksum with IxChariot is only supported on Windows operating systems and on Linux,
including the Ixia endpoint. It is possible to disable it manually on FreeBSD UNIX, IBM AIX, SCO UnixWare, and
Solaris, but the new setting affects all UDP connections on this computer until you manually reset it or restart
the computer. Instructions for disabling the checksum on these operating systems are provided below.
l To disable the UDP checksum on FreeBSD UNIX, do the following:
Go to the /sbin directory.
Enter the following at a command prompt (this command requires super-user privileges):
./sysctl -w net.inet.udp.checksum=N
where N=1 enables the UDP checksum and N=0 disables it. The change lasts until you restart. To see
the current setting, enter the following:
./sysctl -a | grep net.inet.udp.checksum
The first number shown is the current setting, the second is the default setting, and the others do not
apply.
l To disable the UDP checksum on IBM AIX, do the following:
Go to the /usr/sbin directory.
./nfso -o udpchecksum=N
./nfso -o udpchecksum
l To disable the UDP checksum on SCO UnixWare 2.1, do the following:
Go to the /etc/conf/bin directory.
- 23 -
./idtune UDPCKSUM N
./idtune -g UDPCKSUM
l To disable the UDP checksum on Solaris, do the following:
Go to the /usr/sbin directory.
./ndd -set /dev/udp udp_do_checksum N
./ndd /dev/udp udp_do_checksum
- 24 -
Setting the Transmit MSS Option

The Maximum Segment Size is defined as the maximum number of bytes in the TCP payload of an IP/TCP
packet. A TCP/IP stack must be able to reassemble packets of every size. NEMs can use the MSS option to test
the impact of packet size on throughput and latency when passing packets through their devices.
Different packet sizes will result in very different memory allocation patterns on the DUT, stressing different
aspects of its implementation, possibly exposing bottlenecks or mis-implementations.
This MSS option will provide an upper limit on the size of transmitted packets, which does not mean that pack-
ets cannot be smaller. Typically the last fragment of a data stream will be a smaller size.
The MSS option as discussed in this document is different from the TCP header option MSS (MSS advert-
isement), which is usually set in the SYN packets establishing a TCP connection.
Let us consider the following example. Hosts E1 and E2 are communicating with each other, advertising MSS
values of 1,000 and 800, respectively.
[E1] --- SYN [TCP MSS=1000]---> [E2]

[E1] <--- SYN/ACK [TCP MSS=800] --- [E2]
If no MSS option is specified in the IxChariot script, the resulting packet sizes would be as follows:
[E1] --- TCP [payload 800 bytes] ---> [E2]

[E1] <--- TCP [payload 1000 bytes] --- [E2]
However, when an MSS option is specified in the script (for example, 500 bytes for E1 and 400 bytes for E2),
the packets would be sized as follows:
[E1 MSS: 500]--- TCP[payload 500 bytes]--->[E2 MSS: 400]

[E1 MSS: 500]<---TCP[payload 400 bytes]--- [E2 MSS: 400]
In other words, the MSS option specified in an IxChariot script will override the MSS value advertised by the
port's TCP stack during the TCP handshake. Note also that the two MSS options are affecting the TCP flow in dif-
ferent directions. The TCP advertisement MSS is defining the maximum packet size that a host can receive,
whereas the MSS socket option (as defined in this document) is defining the size of packets being transmitted
from a host. Accordingly, the options could also be called "transmit MSS" (socket option) and "receive MSS"
(TCP advertisement).
- 25 -
Script Editor User Interface Reference

This section provides a reference for the IxChariot Script Editor user interface, organized into the following top-
ics:
l The File Menu
l The Edit Menu
l The Insert Menu
l Script Editor Toolbar
l Shortcut Keys for the Script Editor
- 26 -
The File Menu
Your options in the File menu vary slightly, depending upon the method you use to accessed the Script Editor
(refer to Accessing the Script Editor). The Script Editor File menu provides these following options:
l New
Open an IxChariot script template to use as the basis of a new script. When you select New, the Script
Editor opens the New Script dialog, listing the available script templates. Refer to Adding a New Script
for a description of the script templates.
l Open
Open an IxChariot script file (an .scr file).
l Save to Pair
Save your modified IxChariot script file to disk, using the original script file name. The changes you
make to the script will apply only to the script used by a single pair.
l Save to File
Save the current IxChariot script file to disk using a different name. The changes you make to the script
will apply to the script file itself, which means that any pair using this script will always use your modified
version after you save your changes.
l Save
Save the current IxChariot script file to disk, using the original script file name. The changes you make to
a script will apply to the script file itself, which means that any pair using this script will always use your
modified version after you save your changes. (This menu options appears only when you select Edit
Scripts from the Tools menu.)
l Save As
Save the current IxChariot script file to disk using a different name. The changes you make to the script
will apply only to the renamed script. (This menu options appears only when you select Edit Scripts
from the Tools menu.)
l Validate script
Check the script for errors and inconsistencies.
l Exit
Exit the Script Editor.
- 27 -
The Edit Menu
The menu items in the Script Editor's Edit menu let you work with the script that is currently open.
l Undo
Lets you undo an unlimited number of previous actions in the Script Editor. However, this menu item is
only available if your last action was something other than clicking the Undo menu item.
l Redo
Lets you reverse your last Undo and return the script to the state it was in before you clicked Undo. Only
available when your last action was Undo.
l Delete
Deletes commands and variables from a script. First, highlight the command or variable you want to
delete by clicking the command or variable.
l Move Up
Moves a variable up in the sequence of commands in a script. To keep the script valid, this menu item is
only available when moving the highlighted variable up in a valid scripting choice. In some cases, the
Move Up function may cause the highlighted variable to move up to the next valid place in the script or
may cause other variables to move.
l Move Down
Moves a variable down in the sequence of commands in a script. To ensure a valid script, this menu
item is only available when moving the highlighted variable down is a valid move. In some cases, the
Move Down function may cause the highlighted variable to move down to the next valid place in the
script or may cause other variables to move.
l Swap Sides
Moves a command to the opposite endpoint or reverses a command pair. For example, if you highlight
SEND/RECEIVE and use the Swap sides functionality, the command pair is now RECEIVE/SEND. Only
available for certain commands.
l Edit Parameter
Lets you change a command's parameters and assign the command as either a constant or a variable.
See Editing a Parameter of a Script Command for more information on editing parameters.
l Edit Variable
Lets you change a variable's name, description, value, and default value. See Editing a Script Variable
for more information on editing variables.
- 28 -
The Insert Menu
The Insert menu lets you insert the following commands into the script:
Table 4-4. Insert Menu Functions
Script Com-
Description
mand
CONNECT Creates a connection. Also inserts a DISCONNECT command.
SEND from
Sends a buffer of the size and type you specified from E1 and receives data at E2.
Endpoint 1
SEND from
Sends a buffer of the size and type you specified from E2 and receives data at E1.
Endpoint 2
CONFIRM
from End- Requests an acknowledgment from E2 that the previously-sent data has been received.
point 1
CONFIRM
from End- Requests an acknowledgment from E1 that the previously-sent data has been received.
point 2
WAIT at Instructs a script running on Endpoint1 to pause its execution and listen for a SIGNAL from
Endpoint 1 another script.
WAIT at Instructs a script running on Endpoint2 to pause its execution and listen for a SIGNAL from
Endpoint 2 another script.
SIGNAL at Instructs a script running on Endpoint1 to SIGNAL an "event" to the script that is waiting to
Endpoint 1 resume execution upon receipt of that event.
SIGNAL at Instructs a script running on Endpoint2 to SIGNAL an "event" to the script that is waiting to
Endpoint 2 resume execution upon receipt of that event.
UDP com-
Selects the UDP network protocol implementation that is compliant with RFC768. This is valid
pliant with
for unicast and multicast streaming scripts only. If you do not select this option, IxChariot uses a
RFC768
proprietary implementation of UDP that enables the collection of additional test statistics.
option
SLEEP at
Simulates a user or processing delay at E1.
Endpoint 1
SLEEP at
Simulates a user or processing delay at E2.
Endpoint 2
Nagle
option at Disables the Nagle algorithm for TCP sending from E1.
Endpoint 1
Nagle
option at Disables the Nagle algorithm for TCP sending from E2.
Endpoint 2
UDP Check-
sum option
Disables the UDP checksum for UDP sending from E1.
at Endpoint
1
UDP Check-
sum option
Disables the UDP checksum for UDP sending from E2.
at Endpoint
2
MSS option Sets the transmit MSS for E1.
- 29 -
at Endpoint
1
MSS option
at Endpoint Sets the transmit MSS for E2.
2
OPTIONS at the endpoints control the:
l TCP Nagle algorithm see Disabling the Nagle Algorithm.
l UDP checksum see Disabling the UDP Checksum.
l UDP protocol see Selecting RFC768 UDP.
l MSS value see Setting the Transmit MSS Option.
Highlight the location in the script where you want to insert the command, or highlight the group of commands to
insert around it. On the Insert menu, click the command you want to insert in the script.
All scripts must adhere to specific rules. Only the commands that can be inserted at the selected location in the
script are available to you; unavailable commands are dimmed. The location you highlight determines the avail-
able commands. If the command you want to insert is dimmed, try selecting an adjacent location.
- 30 -
Script Editor Toolbar
Many of the Script Editor menu options have a corresponding button on the toolbar. The following is a list of
each function represented by a toolbar button, with a brief description of each:
Table 4-5. Toolbar Buttons
Button Name Description
Validate Script Checks the script for errors and inconsistencies.
Move Up; Move Moves a variable to the next position in the script. Applies only to script
Down variables.
Swap Sides Exchanges the positions of Endpoint 1 and Endpoint 2
Insert Connect Inserts a CONNECT command at the beginning of the script.
Insert Send from E1 Inserts a SEND command from Endpoint 1 at the desired location.
Insert Send from E2 Inserts a SEND command from Endpoint 2 at the desired location.
Insert Confirm from

Inserts a CONFIRM command from Endpoint 1 at the desired location.
E1
Insert Confirm from
Inserts a CONFIRM command from Endpoint 2 at the desired location.
E2
Insert Loop Inserts a LOOP command at the desired location.
The option to choose a normal CLOSE_TYPE for your script does not appear on the Insert menu. To change
the CLOSE_TYPE from abortive (Reset) to Normal, double-click the CLOSE_TYPE variable where it appears in
the lower half of the Script Editor window.
- 31 -
Shortcut Keys for the Script Editor
You can use the following keys and key combinations as shortcuts in the Script Editor window, instead of using
the mouse:
Table 4-6. Shortcut Keys for Script Editor
Key or Key
Command Invoked
Combination
Del Delete the highlighted variable from the script.
Enter Edit the currently-highlighted parameter on a command, or a script variable.
F1 Get help for the Script Editor window.
F2 Show an index of all the available help topics.
F3 Exit the window.

F9 Show the keys and key combinations available in a window.
Open the About dialog box, which shows your version and build level and helps you get
F11
product support information.
Ctrl+E Redo the last operation to the script if you have just chosen Undo.
Create a new script. The New Script dialog box is shown. You can add a new script based on
Ctrl+N
five templates.
Ctrl+O Open an existing script file.
Save a script file, using the filespec shown on the title bar. If the script is still untitled, the Save
Ctrl+S
Script File As dialog box lets you choose a path and file name for the script.
Swap the sides for the currently-highlighted script commands. That is, move the Endpoint 1
Ctrl+W
command to Endpoint 2, and move the Endpoint 2 command to Endpoint 1.
Ctrl+Z Undo the last operation.
Ctrl+ Down Move the currently-highlighted script variable one row lower in the list of variables. You can-
Arrow not move the port_number variable from the bottom of the list.
Ctrl+Up Move the currently-highlighted script variable one row higher in the list of variables. You can-
Arrow not move the port_number variable from the bottom of the list.
This key combination can be used to close any window or dialog box. When used to close a
Alt+F4
dialog box, it has the same effect as clicking the Esc key or clicking Cancel.
In addition to these keys, you can use the Alt key in combination with any underscored letter in a menu item title
to invoke a menu function. The menu function must be visible and not shown in gray. For example, clicking
Alt+F shows the File menu.
- 32 -
Chapter 5: Script Command Reference

This chapter provides a reference for each of the commands that you can use in an IxChariot application
scripts.
l Communication Commands
l Application Commands
l Program Control Commands
- 33 -
Communication Commands
The communication commands establish and disconnect the TCP sessions between the communicating end-
point computers, manage the send and receive buffers used for data transfers, and effect the transfers of data
between the endpoints. The communication commands include:
l CONNECT_INITIATE
l CONNECT_ACCEPT
l SEND
l RECEIVE
l CONFIRM_REQUEST
l CONFIRM_ACKNOWLEDGE
l DISCONNECT
CONNECT_INITIATE
Command Description
Initiates establishment of a connection from Endpoint1 to Endpoint2.
Parameters
This command takes three parameters:
l Source Port:
You can specify a specific source port number or you can select AUTO to allow the script to auto-
matically assign the port number. Selecting AUTO generally gives the best performance.
You may need to enter a specific port number when your script emulates a specific application. Spe-
cifying specific port numbers is also useful when testing devices that filter traffic based on their port num-
ber, such as firewalls.
Use AUTO if possible when testing with multiple pairs. If the same port is specified for multiple pairs, the
performance degrades, since the pairs must share (serialize) the use of the port to run the test.
l Send Buffer Size on E1:
This variable specifies the send-buffer space that the Endpoint operating system is requested to reserve
for this connection.
l Receive Buffer Size on E1:
This variable specifies the receive-buffer space that the Endpoint operating system is requested to
reserve for this connection.
Usage Notes for CONNECT and DISCONNECT

The following rules apply to the CONNECT_INITIATE, CONNECT_ACCEPT, and DISCONNECT commands:
l Only one connection at a time is allowed in an application script.

l Nested connections are not allowed, although you can have many connections back-to-back.
l Endpoint 1 initiates all connections, and therefore issues the CONNECT_INITIATE command.
l Endpoint 2 always issues CONNECT_ACCEPT.
l Each CONNECT command has a corresponding DISCONNECT in the same loop, at the same loop
depth, possibly 0.
l The source_port parameter is set at Endpoint 1, and the destination_port parameter is set at Endpoint
- 34 -
2. They need not have the same value. Their values are in the range 1 to 65,535 or the value AUTO.
l The CONNECT_INITIATE and CONNECT_ACCEPT commands use the send_buffer parameter and the
receive_buffer parameter to specify how much buffer space the operating system should allocate for
the sockets datagram service:
l UDP traffic:
For UDP traffic, these parameters specify how many bytes the operating system can store before
data loss occurs.
l TCP traffic:
For TCP traffic, these parameters specify how much buffer space the operating system should
allocate for the TCP sliding window service. This supports the RFC 1323-specified TCP window
scale option, which allows a TCP window size in excess of 64KB. You can specify a buffer size
up to 2,147,483,646 bytes. (For a detailed description of this topic, refer to the "Modifying the
TCP Window Size" topic in the IxChariot User Guide.)
l Previously, 0 was identified with the DEFAULT value; DEFAULT is now 2,147,483,647 bytes.
In general, you will want larger send and receive buffers for fast networks and for bursty traffic.
CONNECT_ACCEPT
Command Description
Causes Endpoint2 to accept the TCP connection initiated by Endpoint1.
Parameters
This command takes the same three parameters as the CONNECT_INITIATE command: port, send_buffer, and
receive_buffer. The port variable specifies the destination_port for the CONNECT_INITIATE command.
l Destination Port:
You can specify a specific destination port number or you can select AUTO to allow the script to auto-
matically assign the port number. Selecting AUTO generally gives the best performance.
You may need to enter a specific port number when your script emulates a specific application. Spe-
cifying specific port numbers is also useful when testing devices that filter traffic based on their port num-
ber, such as firewalls.
Use AUTO if possible when testing with multiple pairs. If the same port is specified for multiple pairs, the
performance degrades, since the pairs must share (serialize) the use of the port to run the test.
l Send Buffer Size on E2:
This variable specifies the send-buffer space the Endpoint operating system is requested to reserve for
this connection.
l Receive Buffer Size on E2:
This variable specifies the receive-buffer space the Endpoint operating system is requested to reserve
for this connection.
Usage Notes
Refer to Usage Notes for CONNECT and DISCONNECT.
SEND
Command Description
The SEND command sends data (a record or a file) to the other endpoint. It can be issued by either Endpoint1
or Endpoint2.
- 35 -
Parameters
The SEND command has four parameters:
l Send Data Size: The number of bytes to send.
l Send Buffer Size: The size of buffers to use on each SEND.
l Send Data Type: The type of data to send.
l Send Data Rate: The rate at which to send the data.
For example, if you chose "SEND 1000, 100, ZEROS, UNLIMITED," the endpoint will send 1,000 bytes, 100
bytes at a time, with all zeros as data, as fast as possible. This SEND command will result in 10 Send calls to
the communications API.
Usage Notes for SEND and RECEIVE

The following rules apply to the SEND and RECEIVE commands:
l SEND may only take place inside a connection.

l No more than 1,000 SEND commands can be contained in a single script.
l The size parameter specifies the number of bytes to send in each transmission. It can be set from from 1
to 2,147,483,647 bytes, inclusive.
l You can use the same variable for the size and buffer parameters to ensure that the data are always
sent in one block.
l A script can support a maximum of 4GB of payload data for one endpoint. The script can include any
number of payload files as long as their total size does not exceed 4GB.
l The two endpoints may have different buffer sizes on a corresponding SEND/RECEIVE pair again, from
12,147,483,647 bytes, inclusive or the value DEFAULT.
l The data type (send_datatype parameter) is selected from one of the defined data types. (Refer to
Providing Script Payload for more information about the data types.)
l The buffer parameter allocates the send and receive buffers for the endpoints: send_buffer_size
determines how many bytes of data are included with each SEND, and receive_buffer_size determ-
ines how many bytes are included in each RECEIVE. The maximum size in each case is 2,147,483,647
bytes of data.
RECEIVE
Command Description
The RECEIVE command receives the data that was sent by the other endpoint. It can be issued by either
Endpoint1 or Endpoint2. When you add a SEND command to a script, the Script Editor automatically adds the
corollary RECEIVE command for the opposite endpoint.
Parameters
The RECEIVE command has two parameters:
l send_data_size: The number of bytes that will be received.
l receive_buffer_size: The size of receive-buffers to use for each RECEIVE.
Usage Notes
Refer to Usage Notes for SEND and RECEIVE.
- 36 -
CONFIRM_REQUEST
Command Description
The CONFIRM_REQUEST command can be issued by either Endpoint 1 or Endpoint 2. It requests that the
other endpoint confirm that it has received the data from the sending endpoint.
Parameters
The CONFIRM_REQUEST command has no parameters.
Usage Notes for CONFIRM Commands

The following rules apply to the CONFIRM_REQUEST and CONFIRM_ACKNOWLEDGE commands:
l CONFIRM_REQUEST can only occur within a connection, after a SEND that has not already been
CONFIRMed.
l A CONFIRM_REQUEST command is on the same endpoint as the most recent SEND.
l CONFIRM commands are not allowed inside a loop after a SEND, such that it could be repeated more
times than the SEND.
CONFIRM_ACKNOWLEDGE
Command Description
When you add CONFIRM_REQUEST command to a script, the Script Editor automatically adds the corollary
CONFIRM_ACKNOWLEDGE command. The CONFIRM_ACKNOWLEDGE command.sends a one-byte data
record to the endpoint that requested the confirmation.
Parameters
The CONFIRM_REQUEST command has no parameters.
Usage Notes
Refer to Usage Notes for CONFIRM Commands.
DISCONNECT
Command Description
The DISCONNECT command closes the connection that was established with the CONNECT_INITIATE com-
mand.
Parameters
This command has one parameter (close_type) that specifies the type of disconnection required. The dis-
connection types are:
l Reset: The script uses an abortive close, with a RST flag, which closes the connection immediately. With
an abortive close, the protocol stack on the receiving endpoint cannot reclaim network resources taken
up by the connection if the RST is lost, and may linger indefinitely in FIN_WAIT state.
l Normal: The script uses a normal close, with a FIN flag, to close the connection slowly, with acknow-
ledgments from the receiving computer. The normal close specifies that if the FIN is lost, the endpoints
remain in TIME_WAIT state only until the stack's timeout period elapses.
The close_type variable is valid for TCP only. The default value is Reset.
Usage Notes
Refer to Usage Notes for CONNECT and DISCONNECT.
- 37 -
- 38 -
Application Commands
The application commands emulate specific characteristics of an application or the traffic patterns generated by
the application. The application commands include:
l SLEEP
l OPTION
l RTP_PAYLOAD_TYPE
SLEEP
Command Description
The SLEEP command instructs the script to pause for the time specified in milliseconds (ms). SLEEP com-
mands can be used to emulate application processing time or human delays between transactions.
Parameters
The SLEEP command has one parameter: Sleep Time.
Sleep Time is the number of milliseconds that the script will sleep. Sleep Time is either a constant or a ran-
domly-selected number. If you select a constant sleep time, you enter a positive integer in the range 0 to
2,147,483,647. The default value is the constant 0, which means not to sleep. Alternatively, select a type of ran-
dom distribution and the range within which the random sleep times should be generated. Refer to Random Dis-
tributions for more information.
Usage Notes
The following rules apply to the SLEEP command:
l There is no restriction on the placement of SLEEP commands.
However, the location of SLEEP commands in scripts is important. If a SLEEP command occurs before
the timing loop, the timing records do not reflect the impact of the SLEEP command on the test meas-
urements. If the SLEEP command occurs within the timing loop, the results include the effects that the
SLEEP command had on the sending and receiving of data.
l Do not insert multiple SLEEP commands back-to-back. Doing so can cause several problems in the
Script Editor and in exporting these scripts.
Note that not all operating systems can sleep for precise 1 millisecond time periods. For example, the shortest
sleep on NetWare endpoints is 1/18th second; that is, 55 ms. Thus, if you are setting a constant sleep time for a
script that will use NetWare, multiples of 55 are the most efficient due to the granularity of its clock.
See Setting SLEEP Times for more information.
OPTION
Command Description
The OPTION command is used to specify any of the following options on Endpoint 1 or Endpoint 2:
l Disable the Nagle algorithm. Nagle is enabled by default in all IxChariot TCP scripts. It imposes flow con-
trol on TCP/IP networks. Disabling the Nagle algorithm allows you to determine the packet sizes used in
a script. For example, you must disable the Nagle algorithm to perform tests with variable buffer sizes.
l Set the maximum segment size. The max_segment_size variable controls the size of transmitted pack-
ets. When this option is set, the TCP/IP stack will segment the data stream into packets where the TCP
payload is no larger than the value specified.
l Disable UDP checksums. When UDP checksum is disabled, this variable suppresses the generation of
the checksum field of UDP headers.
- 39 -
l Enable RFC768 compliant implementation of UDP. This option selects the UDP network protocol imple-
mentation that is compliant with RFC 768. If you do not select this option, IxChariot uses a proprietary
implementation of UDP to enables the collection of extended test statistics.
Parameters
Each of the variations of the OPTION command provides one parameter:
OPTION Command Parameter For More Information, Refer to:

Nagle Algorithm (TCP only) Disabling the Nagle Algorithm.
Maximum Segment Size (TCP only) Setting the Transmit MSS Option.
UDP Checksum Disabling the UDP Checksum.
UDP compliant with RFC768 Selecting RFC768 UDP.
Notes
The following notes apply to the OPTION command:
l Not not all communications stacks support the UDP Checksum option.
l UDP checksums are disabled by default on all VoIP pairs, if the endpoint operating system allows it.
l Selecting the RFC 768 implementation of UDP is valid for unicast and multicast streaming scripts only. It
is not valid for VoIP or video tests.
RTP_PAYLOAD_TYPE
Command Description
The RTP_PAYLOAD_TYPE command is used only in streaming scripts. It causes Endpoint 1 to set the payload
type field in the RTP packet header to the specified value.
Parameters
The RTP_PAYLOAD_TYPE command has one parameter: RTP Payload Type.
RTP Payload Type identifies the value of the bit pattern that is set in the RTP header. It does not affect the type
of data that is being sent. If you need to send a specific type of data that is not provided by one of the .cmp files,
you can provide user-defined data, as described in Chapter 7, Providing Script Payload. All predefined scripts
default to the correct value for this variable based on the application being emulated.
You can select from our predefined values for the type field. We have defined the most common values for the
payload type. See "Supported RTP Payload Types" for a description each of the payload types you can select
for the type value.
Notes
The following rules apply to the RTP_PAYLOAD_TYPE command:
l The RTP_PAYLOAD_TYPE required is present in all streaming scripts.
l If the protocol is UDP or IPX, this command is ignored.
Supported RTP Payload Types

The RTP_PAYLOAD_TYPE command is used in streaming scripts. It causes Endpoint 1 to set the payload type
field in the RTP packet header to a specified value.
Table 5-1 describes the supported RTP payload types.
Table 5-1. Supported RTP Payload Types
Encoding Payload
Description
Name Type
- 40 -
North American U-law variation of Pulse Code Modulation encoding. Standardized by

PCMU 0
the ITU as G.711.
Global System for Mobile, the de-facto standard for digital cellular in Europe and Asia.
GSM 3
G723 4 Dual-rate 6.3/5.3-Kbps voice encoding scheme.

European A-law variation of Pulse Code Modulation encoding. Standardized by the
PCMA 8
ITU as G.711.
MPA 14 MPEG audio.
Voice codec that uses Adaptive Differential Pulse Code Modulation (ADPCM) for com-
G726 2
pression and a waveform encoding scheme.
G729 18 Voice encoding scheme that produces high quality at a low data rate.
H261 31 The common video codec used with image sizes of 352 x 288 pixels.
MPV 32 MPEG video.

Common video codec used with communication channels that are multiples of 64
H263 34
Kbps and image sizes of 176 x 144.
Joint Photographic Experts Group standard and is used for encoding and com-
JPEG 26
pressing color images.
- 41 -
Program Control Commands

The program control commands provide flow control for a script. The program control commands include:
l LOOP
l END_LOOP
l START_TIMER
l END_TIMER
l INCREMENT_TRANSACTION
l WAIT_EVENT
l SIGNAL_EVENT
LOOP
Command Description
The LOOP command starts a program loop in the script.
Many scripts have two loops: the outer loop controls the number of timing records, while the inner loop controls
the number of transactions per timing record.
Parameters
The LOOP command has one parameter:
l Loop Count: specifies the number of times that the loop will repeat. The Loop Count variable is an
integer in the range of 1 to 2,147,483,647. The default value varies, depending where it is used in each
script. IxChariot scripts use a wide variety of default loop count values to emulate repeatedly running an
application.
Usage Notes for LOOP and END_LOOP

The following rules apply to the LOOP and END_LOOP command:
l The Loop Count variable is ignored if you configure your test to run for a fixed duration.
l Each LOOP has a corresponding END_LOOP.
l The maximum depth of loop nesting is 10.
l The outermost loop of a script must contain all the "important" parts of the script. For example, START_
TIMER, END_TIMER, and INCREMENT_TRANSACTION must be within this loop. This is done because
the number of iterations in this loop is changed when running a test for a fixed duration (rather than a
fixed number of iterations). The loop count parameter matches on the corresponding endpoints, and
can be set from 1 to 2,147,483,647 iterations, inclusive.
END_LOOP
Command Description
The END_LOOP command marks the end of a loop.
Parameters
The END_LOOP command has no parameters.
Usage Notes
Refer to Usage Notes for LOOP and END_LOOP.
- 42 -
START_TIMER
Command Description
The START_TIMER command marks the beginning of a checkpoint, and resets the transaction count to 1.
In streaming scripts, this command is used only in Endpoint 2, which keeps the timings, and accounts for lost
data.
In nonstreaming scripts, this command is used only in Endpoint 1. (Timing records are kept at Endpoint 1 in non-
streaming scripts.)
Parameters
The START_TIMER command has no parameters.
Usage Notes for the START_TIMER, END_TIMER, and INCREMENT_

TRANSACTION Commands
The following rules apply to the START_TIMER, END_TIMER, and INCREMENT_TRANSACTION commands:
l In streaming scripts, there is no INCREMENT_TRANSACTION command. The START_TIMER and

END_TIMER commands occur only in Endpoint 2. In nonstreaming scripts, the START_TIMER, END_
TIMER, and INCREMENT_TRANSACTION commands occur at Endpoint 1, and occur once per script.
l START_TIMER has a corresponding END_TIMER later in the script, in the same loop at the same loop
depth. An INCREMENT_TRANSACTION command occurs somewhere between START_TIMER and
END_TIMER, and this INCREMENT_TRANSACTION must be at a greater loop depth than the START_
TIMER/END_TIMER pair. (This allows the creation of multiple transactions within a timing record.)
l START_TIMER and END_TIMER must be inside a loop (to create multiple timing records), and must be
within the outermost loop of a script.
END_TIMER
Command Description
The END_TIMER command marks the end of a checkpoint and causes a timing record to be generated, which
includes the transaction count.
In streaming scripts, this command is used only in Endpoint 2, which keeps the timings and accounts for lost
data.
In nonstreaming scripts, this command is used only in Endpoint 1.
Parameters
The END_TIMER command has no parameters.
Usage Notes
Refer to Usage Notes for the START_TIMER, END_TIMER, and INCREMENT_TRANSACTION Commands.
INCREMENT_TRANSACTION
Command Description
The INCREMENT_TRANSACTION command increments the number of transactions per timing record. It is
used only in nonstreaming scripts, and every nonstreaming script is required to include one call to the
INCREMENT_TRANSACTION command.
The transaction counter is reset to 1 each time a START_TIMER command is executed. Because timing records
are kept only at Endpoint 1, this command is used only in the Endpoint 1 portion of scripts.
- 43 -
Parameters
The END_TIMER command has no parameters.
Usage Notes
Refer to Usage Notes for the START_TIMER, END_TIMER, and INCREMENT_TRANSACTION Commands.
WAIT_EVENT
Command Description
The WAIT_EVENT command is used in scripts that are included in IxChariot application groups. Such scripts
synchronize their operations with one or more concurrently-running scripts. When an IxChariot script executes
a WAIT_EVENT command, it pauses execution until it receives a signal to resume execution. The signal is
received from another script that executes a SIGNAL_EVENT command with the same event parameter.
Parameters
The WAIT_EVENT command has two parameters:
l Synchronization Wait Event: A named object uniquely defined within an application group.
l Synchronization Wait Type: Specifies whether the wait time is measured or unmeasured in the timing
records.
Usage Notes for WAIT_EVENT and SIGNAL_EVENT

The following rules apply to the use of WAIT_EVENT and SIGNAL_EVENT commands in nonstreaming scripts:
l A WAIT_EVENT command must have at least one corresponding SIGNAL_EVENT command and this
SIGNAL_EVENT command must be executed on the same machine as the WAIT_EVENT.
l Each event can be referenced by a maximum of one WAIT_EVENT command.
l A WAIT_EVENT command should be followed by a SEND or a CONNECTINIT command. This ensures
that the other endpoint will execute a blocking command, such as RESV or CONNECT ACCEPT.
l For nonstreaming scripts, a measured WAIT_EVENT can be located on either Endpoint1 or on
Endpoint2. An unmeasured WAIT_EVENT can be located only on Endpoint1.
The following rules apply to the use of WAIT_EVENT and SIGNAL_EVENT commands in streaming scripts.
l A streaming pair (including VoIP) can have any number of WAIT_EVENT commands on Endpoint1.
These commands can appear anywhere in the script.
l A streaming pair (including VoIP) can have any number of SIGNAL_EVENT commands on Endpoint1
and Endpoint2. These commands can appear anywhere in the script. However, because streaming is
unidirectional (from Endpoint1 to Endpoint2), WAIT_EVENT commands cannot be added on
Endpoint2.
Refer to "Synchronized Pair Testing" in the IxChariot User Guide for detailed information about application
groups, events, and the WAIT_EVENT and SIGNAL_EVENT commands.
SIGNAL_EVENT
Command Description
The SIGNAL_EVENT command is used in scripts that are included in IxChariot application groups. Such scripts
synchronize their operations with one or more concurrently-running scripts. When an IxChariot script executes
a SIGNAL_EVENT command, it causes another script which previously executed a WAIT_EVENT command to
resume execution.
For example, if Script-A executes a WAIT_EVENT (event1,measured) command, it pauses until another script in
the same application group executes a SIGNAL_EVENT (event1) command.
- 44 -
Parameters
The SIGNAL_EVENT command has one parameter:
l Synchronization Signal Event: A named object uniquely defined within an application group.
Usage Notes
Refer to Usage Notes for WAIT_EVENT and SIGNAL_EVENT.
- 45 -
Chapter 6: Configuring IxChariot Script

Variables
This chapter provides detailed information about the variables that you can configure in IxChariot scripts.
l Script Variable Overview
l Setting Source and Destination Ports
l Setting the SEND Data Rate
l Setting the SEND Data Type
l Setting the SEND/RECEIVE Buffer Size
l Setting SLEEP Times
l Random Distributions
- 46 -
Script Variable Overview

Script variables are used to allow command parameters to be changed globally within a script. Variables can
be used to control LOOP counts, to define port numbers, to specify the data type for a SEND, specify buffer
sizes, and so on.
Script Variable Rules

The following are the general rules that govern the use of variables in a script:
l A parameter is set to the value of a variable. For example:
LOOP
count = number_of_timing_records (50)
In this example, the parameter name is count, and the variable name is number_of_timing_records, and
the current value is 50.
l The name of a variable must be unique within a script, and must not contain spaces.
l Non-zero integer variables can be used for loop count, file size, and buffer size. Values from zero to
2,147,483,647 are accepted.
l Variables used for loop count may not be used for any SEND parameter, and vice versa.
l AUTO, when entered for the source or destination_port variables, specifies that the TCP stack should
dynamically choose available ports to use in the test.
l Integer variables that allow the keyword DEFAULT are used only for buffer size. A Performance End-
point will resolve the DEFAULT keyword based on the network protocol and the endpoints you are
using.
l Random Distribution variables can be used only for sleep times and send and receive buffer sizes.
l Each variable has a variable type, depending on its usage as a command parameter. The variable type
is not exposed, per se.
Default Value Versus Current Value

Each script variable has two values: the Current Value and the Default Value:
l Scripts always use the Current Value defined for a variable. When you want to alter the value assigned
to a variable, you must change the Current Value. Changing the Default Value field has no effect.
l The Default Value field provides a simple means to return to a known value when you are modifying
script variables. A good rule of thumb is to always leave the Default Values set to their original, as-
installed values. This way, if you change a Current Value and the script subsequently fails, you can
return to the Default Value to start troubleshooting from a known point of reference.
The Edit Variable dialog box provides a Reset button that sets the Current Value equal to the Default Value.
- 47 -
Setting Source and Destination Ports

IxChariot lets you specify both the source and destination port numbers to use for connections between end-
points if the protocol is TCP, UDP, or RTP. With the script open in the Script Editor, double-click the source_port
variable under E1, or the destination_port variable under E2 in the script to edit them.
When editing these script variables:
l Click AUTO to let the endpoints assign the port number automatically, or
l Enter the port number(s).
Using AUTO
Setting the port number to AUTO gives the best performance and is the preferred choice when testing with mul-
tiple pairs.
Using Specific Port Numbers

Enter a port number between 1 and 65,535, if you are trying to emulate a particular application. Specific port
numbers are useful when testing devices that filter or prioritize traffic based on their port number, such as fire-
walls or Layer 3 switches. We recommend saving the script file with a new name when you specify port num-
bers so that you can easily reuse it with other pairs or in other tests.
When using specific port numbers, the following restrictions apply:
l You should plan to stop any other applications using these port numbers before you begin testing with
them.
l Only one pair at a time can use a port number for each datagram protocol (that is, RTP, IPX, or UDP).
For example, only one endpoint at a time can use port number 1234 with UDP.
l Endpoints running on IBM MVS allow only one pair at a time with the same port number. This restriction
is based on their internal tasking structure. Expect to see message CHR0264 if you attempt to use the
same port number more than once in a test with MVS endpoints.
l You should not replicate endpoints whose source and destination ports have been set. The test will not
run, or you may see CHR0206, which states that the port is already in use.
l With TCP, use only long connection scripts with endpoints whose source and destination ports have
been set. The short connection scripts will cause extremely long delays. Particularly with a TCP normal
disconnect, as soon as the endpoints establish the first connection, that connection will remain in TCP
TIME_WAIT state for between 1 and 4 minutes for each connection instead of closing the connection
and releasing the port for the rest of the test script.
l When testing with a NAT-enabled firewall, you may see differences in the line trace even though the test
will still use the ports you specified.
Port Number Categories

RFC 1700 lists the registered port numbers (on the Web, see ftp://ftp.isi.edu/in-notes/rfc1700.txt). Here are the
categories of port numbers:
Table 6-1. Registered Port Ranges
Port Range Reserved for
1 to 1023 Well-known services (for example, FTP)
1024 Internet Assigned Numbers Authority
1025 to 49151 Registered ports for applications
49152 to 65535 Dynamic or private ports
- 48 -
When setting the port number in a script, consult the user documentation for the application that you are trying
to emulate to find out which port numbers it uses.
See Firewall Testing in the IxChariot User Guide for detailed information on setting the port numbers when
using firewalls.
- 49 -
Setting the SEND Data Rate

The send_data_rate script variable on the SEND command controls the rate the data are sent over the protocol.
You can send data at a specific rate over all supported protocols. You may want to set a specific data rate when
generating a constant amount of network traffic or emulating multiple slower links across a single higher speed
link. The data rate calculated by the endpoint is based on the amount of data specified. Because this rate does
not include protocol and link-layer data lengths, the actual bandwidth consumed in the network is slightly
higher than the send_data_rate you specify.
Selectable Data Rates

You can modify the send_data_rate in the script that you are creating or editing. You can manually enter a
value or select one of the following standard rates:
l 28.8 kbps (modem)

l 33.3 kbps (modem)
l 56 kbps (modem)
l 64 kbps (Fractional T1)
l 128 kbps (Fractional T1/ISDN)
l 1.544 Mbps (T1)
l 2.048 Mbps (E1)
l 8.448 Mbps (E2)
l 10 Mbps (Ethernet)
l 44.736 Mbps (T3)
l 155.52 Mbps (OC-3)
l UNLIMITED
The endpoint sending the data calculates how fast to send it, and then sends it continuously while the timing
record is being generated. The total amount of data per timing record is divided by the buffer size to get the
amount of data for each send.
For streaming tests containing multicast groups, the Endpoint 2 or receiver calculates the throughput in the tim-
ing record. You may notice that the throughput is a slightly less than the rate you specified.
Send-Data-Rate Guidelines
Here are some guidelines for achieving a constant send_data_rate:
l When your test includes multiple pairs, avoid using UNLIMITED as the data rate. It is very possible for
one pair to consume all available bandwidth, which will cause the other pairs in the test to time-out.
l Send a large amount of data with respect to the buffer size and rate. For example, if you are using a buf-
fer size of 8K, setting a send_data_rate of 1 million bytes will give you a more consistent data rate. The
faster the rate, the more data you need to send to achieve a constant rate. Be aware that the default buf-
fer size varies based on network protocol and operating system.
l When trying to achieve a constant send rate, some scripts are better than others. Scripts that have
CONNECTs within a timing record are not good for trying to attain a steady send data rate. Scripts that
contain only sends within a timing record are better for achieving a steady send rate.
l When running streaming tests, use the UNLIMITED send_data_rate with caution. UNLIMITED sends
data as fast as possible. Using this rate may flood the network switches and adversely affect network per-
formance.
l The timers in different endpoint platforms have different resolutions. The resolution affects the accuracy
we can achieve with the send data rate. Some experimentation may be necessary to find the best send_
- 50 -
data_rate to use for your endpoint platform.

l As you increase the rate at which data are sent, you may need to increase the amount of data being
sent. The more data sent in the timing record, the more opportunity the endpoint has to smooth out the
rate. For example, when sending at 10 Mbps, you may need to send 1 million bytes of data per timing
record to achieve a constant rate. The amount of data may need to be increased proportionately as the
rate increases. Some experimentation may be necessary.
l If you experience unacceptable throughput spikes in your streaming tests, you can enable and configure
the data rate optimization run options, either globally or for a specific test. To access these options, first
open the Run Options window by selecting Run > Set Run Options from the main menu, then select the
Datagram tab. For detailed information, refer to the Data Rate Optimization Options topic in the IxChariot
User Guide.
- 51 -
Setting the SEND Data Type

The send_data type variable on the SEND command determines the contents of the data that is sent to the
other endpoint. For example:
SEND
size = file_size (1000000)
buffer = send_buffer_size (65535)
type = send_datatype (NOCOMPRESS)
rate = send_data_rate (UNLIMITED)
Refer to Chapter 7, Providing Script Payload, for a detailed description of this topic.
- 52 -
Setting the SEND/RECEIVE Buffer Size

The send_buffer_size script variable on the SEND command determines the size of the buffer to use for each
SEND command. You can set the buffer size to a constant value or allow the script to set it using one of four dis-
tributions.
Types of Buffers in IxChariot Scripts

IxChariot scripts use two distinct types of buffers:
l TCP and UDP connection buffers: For detailed information about TCP connection buffers, refer to "Modi-
fying the TCP Window Size" in the IxChariot User Guide.
l SEND/RECEIVE buffers: These buffers are described in the topics that follow.
SEND and RECEIVE Buffers

The SEND and RECEIVE commands define buffers that are internal to the endpoints. They determine how
much data will be sent to the TCP stack for processing for each SEND and RECEIVE operation.
For example, the send_buffer_size variable defines this buffer in the Ultra_High_Performance_Throughput.scr
script:
. . .
12 SEND
13 send = size_of_record_to_send (2147483647)
14 buffer = send_buffer_size (1048576)
. . .
By default, an IxChariot application script sends the same amount of data for every SEND command. In the
case of TCP applications, the buffer size in a script and the actual datagram size are not identical because the
Nagle algorithm causes the TCP/IP stack to combine small datagrams into larger ones. But in streaming scripts,
the send_buffer_size in the script and the actual size of datagrams are identical.
Using a Constant Value for Buffer Size

When you select "Constant value" for the send_buffer_size variable, you choose from among the following
options:
l Set the buffer size to a specific value. For example, the High Performance Throughput script sets the buf-
fers to a size of 65,535 bytes.
l DEFAULT Specifies that the endpoint will use buffers that are of the default size for the network protocol
being used. DEFAULT lets you use the default buffer size for each protocol, without having to modify the
script to handle protocol differences. The default value is different depending on the protocol and plat-
form being used.
Some scripts use the same variable for the send size and the buffer size. This ensures that the data are always
sent in one block.
Using Random Buffer Sizes for the SEND Command

Some applications send data using varying buffer sizes. For example, streaming applications may not buffer
smaller packets and send them out in larger chunks, but instead send data as quickly as it becomes available.
The ability to choose a random buffer size lets you emulate bursty traffic and some widely used commercial
applications, such as stock-ticker applications and video conferencing applications. IxChariot lets you emulate
these applications by choosing a random_buffer_size variable for the SEND command.
To have the endpoint send data of varying packet sizes, configure the test as follows:
l Use one of the random distributions: Uniform, Normal, Poisson, or Exponential. Refer to Random Dis-
tributions for a description of each of the distribution models.
- 53 -
l If you are using a connection-oriented protocol, disable the Nagle algorithm. Otherwise, Nagle determ-
ines that data will be gathered into maximum segment-sized (MSS) chunks before it is sent. Refer to Dis-
abling the Nagle Algorithm.
When you are using a connectionless protocol UDP, RTP, or IPX the buffer size determines the payload size of
datagrams sent over the network.
The RECEIVE command that corresponds to the SEND command in a particular script cannot be edited to use
a random buffer size. In most cases, it is the same size as the SEND buffer_size. The table below summarizes
the behavior of the RECEIVE command, depending on the SEND buffer_size you select: either Constant,
DEFAULT, or Random distribution. (Random distributions are Uniform, Normal, Poisson, and Exponential.
Refer to Random Distributions for more information.)
RECEIVE buffer_size Parameter

SEND buffer_
size Para- Constant DEFAULT Random
meter
The effective RECEIVE The effective RECEIVE buffer size

The effective RECEIVE buffer
buffer size is the same is the upper limit of the RECEIVE
Constant size is the same as the SEND
as the RECEIVE com- command's random variable; it is
default buffer size
mand's Constant value not randomly generated
The effective RECEIVE The effective RECEIVE buffer size
The effective RECEIVE buffer
buffer size is the same is the upper limit of the RECEIVE
DEFAULT size is the same as the
as the RECEIVE com- command's random variable; it is
RECEIVE default buffer size
mand's Constant value not randomly generated
Random (Uni- The effective RECEIVE The effective RECEIVE buffer The effective RECEIVE buffer size
form, Normal, buffer size is the same size is the upper limit of the is the upper limit of the RECEIVE
Poisson, and as the RECEIVE com- SEND default buffer size; it is command's random variable; it is
Exponential) mand's Constant value not randomly generated not randomly generated
Randomizing Buffer Sizes

Random buffer sizes are not available for variables that are already being used by other parameters because
most parameters do not support random values. For example, in the Backweb Signup and Info Pack Download
scripts (Bkwbsign), the variable size_of_record_to_send is used by the parameters Send Data Size, Send
Buffer Size, and Receive Buffer Size. The Send Data Size parameter cannot use a randomly selected dis-
tribution. Therefore, you cannot use a random distribution for the size_of_record_to_send. To use a random buf-
fer size, you must replace the size_of_record_to_send with any variable of random type. The Script Editor
creates a random_buffer_size variable that you can use if there is a conflict.
Here is what you need to do:
1. In the lower half of the Script Editor window, find the random_buffer_size variable in the list. You may
need to scroll down to see it.
2. Double-click to edit it.
3. Choose one of the four random distributions from the Current Value list.
4. Set a lower and an upper limit for your buffer size in the fields provided. You must enter a value between
1 and 2147483647 in each field, and the lower limit must be less than the upper limit.
The new variable is available in the Variable Name list. Now you can edit a parameter, such as Send Buffer
Size, so that it uses your new variable.
- 54 -
Setting SLEEP Times

The time parameter value on the SLEEP command lets you emulate delays caused by user actions or pro-
cessing time. The SLEEP command does not consume CPU cycles; it only simulates a delay, not the CPU or
disk overhead that a real application might use.
The Current Value field in the Script Editor Edit Variable dialog box lets you change the amount of time to sleep.
By default, scripts have their delay values set to a Constant value of zero, which means that endpoints execute
scripts as quickly as possible.
Standard SLEEP Variables

There are three standard SLEEP variables that you can select:
l delay_before_responding
This variable lets you simulate a user delay or processing at the endpoint. Before the next script com-
mand is executed, the endpoint sleeps for the number of milliseconds specified.
l transacton_delay
This variable lets you control how frequently transactions are executed. You can set the number of mil-
liseconds to sleep before starting to execute additional commands. This is normally used to simulate an
end user running a transaction on a regular basis; for example, once every 1 second.
l initial_delay
The initial_delay variable is different from the other sleep variables. The longest allowable time for ini-
tial_delay is 90 minutes that is, 5,400,000 ms. Longer values cause Endpoint 2 to time out, and the con-
nection fails.
SLEEP Variable Durations

Sleep time can be set to a constant duration, or it can be randomly distributed using one of four distributions.
When choosing a random distribution, be sure to choose upper and lower limits that are far enough apart for
the endpoints to create a range of random sleep times. If the limits are too close together, you will not see the
effects of random sleeps. For example, a lower limit of 5 ms and an upper limit of 7 ms will not provide enough
variance for interesting random sleeps.
The type of variable used for the SLEEP command or for send and receive buffer sizes allows only five values:
Constant Value, Exponential, Normal, Poisson, and Uniform Distribution. The Constant Value is a single value,
but each distribution is entered as a range. All sleep values are in milliseconds (ms). For more information, see
"Setting SLEEP Times". All buffer sizes are in bytes. See "Using Random Buffer Sizes for the SEND Command"
for details.
Guidelines for SLEEP Variables

Guidelines for determining the values for the upper and lower limits depend on the purpose of the specific
SLEEP command:
l If you are using a SLEEP command for an initial_delay, a lower limit of 0 and an upper limit of 1,000
(that is, 1 second) will emulate the random effects of a large network.
l If you are using a SLEEP command for a delay_before_responding, tailor the values to the activity that
you are emulating. If you are using this parameter to control throughput, use a narrow range between
the upper and lower limits and relatively small values. The upper limits should not exceed 100, since
large values cause measured throughput to reduce rapidly.
l Another use of the delay_before_responding is to emulate the delay time on a server or client-server
application. In this case, a reasonable lower limit is 5. You should use high upper limits. For example, if
you are emulating a three-tiered application, the upper limit should be several thousand milliseconds.
l If you are using a SLEEP command for a transaction_delay, the values should emulate the rate at which
transactions are happening based on the number of users. You should determine the typical delay
- 55 -
between a user's transactions and convert the amount of time to milliseconds (ms).
For example, if you are emulating users transferring files, and the average user transfers a file every 20
minutes, there is a typical delay of 20 minutes. 20 minutes is equal to 1,200,000 ms. Divide this time by
the number of users. If you have 10 users, the 1,200,000-ms delay time is reduced to 120,000 ms. This
figure determines the upper and lower limits for SLEEP. For the lower limit, reduce this time by 10%. In
this example, use a lower limit of 120,000. For the upper limit, increase this time by 10%. In this
example, use an upper limit of 12,000,000.
As a general rule, if you are emulating a large number of users, use small values for the upper and
lower distributions. If you are emulating a small number of users, you should use large values.
- 56 -
Random Distributions
You can specify random distributions for SLEEP times and for SEND buffer sizes. The four possible random dis-
tributions are Uniform, Normal, Poisson, and Exponential.
When you choose one of these random distributions, you specify the upper and lower limits for the random
times that are generated. This appears in the script in the following format:
parameter = variable (distribution(lower, upper))
For example, if you choose a Poisson distribution for a SEND buffer, the parameter will appear as follows in the
script:
buffer = send_buffer_size (p(64, 1460))
In this example, "p" represents Poisson, the lower limit is 64 bytes, and the upper limit is 1,460 bytes.
Uniform Distribution
In the following graph, the distribution of sleep times between the upper and lower limit is completely uniform.
Any number within the upper and lower limits is as likely to be used for the sleep time as any other number. If
you plot the sleep times against the number of occurrences, the graph should be a flat horizontal line.
Figure 6-1. Graph of Uniform Distribution
Normal Distribution
In the following graph, the distribution of sleep times between the upper and lower limits is a normal, or bell-
curved, distribution. If you plot the sleep times against the number of occurrences, the graph should be a bell
curve.
The Marsaglia-Bray algorithm is used to generate the normal distribution. The average value of the distribution
is determined from the upper and lower limit. In a normal distribution, most values occur within +/-3 standard
deviations with respect to the average. The standard deviation is also calculated from the upper and lower lim-
its, as no value exceeds those limits.
Figure 6-2. Graph of Normal Distribution
- 57 -
Poisson Distribution
In the following graph, the distribution of sleep times between the upper and lower limit is a Poisson distribution.
If you plot the sleep times against the number of occurrences, the graph should look like a Poisson distribution.
A typical use of a Poisson distribution is to emulate data inter-arrival rates.
The incomplete gamma function is used to generate the Poisson distribution. The average value of the dis-
tribution is determined from the upper and lower limit. In a Poisson distribution, most values occur within +/-3
standard deviations with respect to the average. The standard deviation is also calculated from the upper and
lower limits, as no value will exceed those limits.
This graph is based on an average and standard deviation. This means that 99% of all values on the graph
should be within +/-3 times the standard deviation. An endpoint calculates the standard deviation by dividing
the difference of the upper and lower limits by three.
Figure 6-3. Graph of Poisson Distribution
Exponential Distribution
- 58 -
In the following graph, the distribution of sleep times between the upper and lower limit is an exponential dis-
tribution. In other words, if you plot the sleep times against the number of occurrences, the graph's maximum
should be at the upper limit and minimum should be at the lower limit.
The lower limit is where the asymptote occurs. The exponential distribution centers on the average of the upper
and lower limit. This should be the average of the distribution. An endpoint uses the average to calculate the dis-
tribution and makes sure that no values exceed the upper limit.
Figure 6-4. Graph of Exponential Distribution
- 59 -
Chapter 7: Providing Script Payload

This chapter focuses on the your options for providing the payload that is transmitted from one endpoint to
another by IxChariot scripts.
l SEND Command Payload Options
l ZEROS and NOCOMPRESS Payload
l Using Calgary Corpus Compression Files
l Using Your Own .cmp Files
l Specifying Embedded Payload Data
l Specifying External Payload Files
- 60 -
SEND Command Payload Options

The send_datatype parameter of the SEND command lets you choose the contents of the data being sent
between the endpoints. You can try different types of data to find out how your network is handling large image
files or compressed data, for example.
In the Script Editor, you specify the data to use with a SEND command by selecting a value for the send_data-
type parameter. When you double-click a Send Data Type variable, the Edit Variable dialog opens. The Cur-
rent Value list and the Default Value list show the options that are available to you.
Table 7-1 lists the options for specifying the data to use with a SEND command.
Table 7-1. Send Data Type Options
Send Data Type
Description
Options
All Zeros.
ZEROS
Refer to ZEROS and NOCOMPRESS Payload.
Randomly-generated bytes.
NOCOMPRESS
Refer to ZEROS and NOCOMPRESS Payload.
Calgary Text Com- Standard data files from the Calgary Text Compression Corpus (most of which have
pression Corpus the file extension .cmp).
Data Files Refer to Using Calgary Corpus Compression Files.
.cmp files that you create. You can supply up to 10 files with your own data. Name the
User-Defined .cmp
files User01.cmp through User10.cmp.
Files
Refer to Using Your Own .cmp Files.
When a Send Data Type variable is set to Embedded Payload (user defined), you spe-
Embedded Payload
cify the payload data for each SEND command from within the script.
(user defined)
Refer to Specifying Embedded Payload Data for detailed information.
When a Send Data Type variable is set to Payload file (user defined), you specify a
Payload File (user data file that can either be embedded within the script or can be externally referenced
defined) by the script.
Refer to Specifying External Payload Files for detailed information.
- 61 -
ZEROS and NOCOMPRESS Payload

For most tests, ZEROS provides the fastest and most uniform type of data. However, you may want to test the
data-compression capabilities of the software and hardware in your network. NOCOMPRESS causes the end-
points to generate random data that is difficult to compress.
The data for types ZEROS and NOCOMPRESS are internally generated by the endpoints. All other types
require .cmp files or user-specified data.
IxChariot generates its random data into a 250K size buffer; when the data from that buffer is transmitted, the
buffer contents are reused from the beginning.
- 62 -
Using Calgary Corpus Compression Files

The Calgary Text Compression Corpus was created by Ian Witten and Tim Bell, researchers from New Zealand
who worked at the University of Calgary in Canada. Their establishment of a standard test suite and a collection
of reference results has proven invaluable.
Several Calgary Corpus data files are included with the endpoints. The file called news.cmp contains a batch of
unedited news articles. Trans.cmp contains a transcript of a terminal session to indicate the increase in speed
that could be achieved by applying compression to a slow line to a terminal. The only non-ASCII file among
those that ship with the endpoints, lena.cmp contains a .gif file.
Ixia also provide other Calgary Corpus data files on the endpoint DVD-ROM and on our Web site. You can
download the Calgary Corpus compression files in zip format from our Web site: http://www.ixi-
acom.com/support/endpoint_library/.
For more information, see the following Web site: http://links.uwaterloo.ca/calgary.corpus.html.
List of Calgary Corpus Files

Table 7-2 summarizes the available Calgary Corpus data files:
Table 7-2. Available Calgary Corpus Compression Data Files
File Name Description
book1, book2, paper1, paper2 Ordinary English, both fiction and non-fiction (ASCII).
bib A bibliography in English (ASCII).
progc, progl, progp Computer programs (ASCII).
geo Geophysical data; difficult to compress.
pic A black and white bitmap image; highly compressible.
- 63 -
Using Your Own .cmp Files

You can create up to ten.cmp files to use as the data for SEND commands in your scripts. You would supply
your own user data for the following situation:
l Data compression is done by the hardware or software in your network, and you want to test per-
formance with the compression activated.
l You have collected a representative sample of the data in your network.
Creating Your Own .cmp Files

Put the data in one or more files. Name the first file User01.cmp, the second file User02.cmp, and so on. Put
your data in the file starting at the beginning; no header is necessary. When sending the data, an endpoint
works sequentially through the file; when it reaches the end, it wraps, appending the first byte of the file to the
last.
The same Userxx.cmp file must reside at all the endpoints you want to test with, and should be placed in the
Cmpfiles subdirectory along with the other Ixia-supplied .cmp files. Files with the same name must contain the
exact same data on each endpoint where they are used if data validation will be used.
HTTP GET Example

In this example, two files (User01.cmp and User02.cmp) are set with an actual sample of data from a network
trace.
User01.cmp
File User01.cmp contains the HTTP GET command (assume 404 bytes):
GET http://www.ixiacom.com/support/chariot_technical_questions.htm HTTP/1.0
If-Modified-Since: Tuesday, 07-Apr-00 20:39:41 GMT; length=16755
Referer: http://www.ixiacom.com/support/chariot_technical_questions.htm
Proxy-connection: Keep-Alive
User-Agent: Mozilla/4.05 [en] (WinNT; I)
Pragma: no-cache
Host: www.ixiacom.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
User02.cmp
File User02.cmp contains the HTTP server response and the actual file (assume 1020 bytes):
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Tue, 21 Jul 2000 22:11:49 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Tue, 07 Apr 2000 20:39:41 GMT
ETag: "92274d4a6562bd1:6457"
Content-Length
"Text file ----"
Test Configuration
Configuration steps:
1. Create a pair and specify the script: HTTPtext.
- 64 -
2. Edit the script and change the following variables:

l destination_port: 80
l size_of_record_to_send: 404
l control_datatype: User01.cmp
l file_size: 1020
l send_datatype: User02.cmp
3. Run the test.
- 65 -
Specifying Embedded Payload Data

When a send_datatype parameter is set to Embedded Payload (user defined), you specify the payload data for
each frame from within the script.
Figure 7-1 shows an example of the Edit Parameter dialog for the send_datatype variable when the Embed-
ded Payload (user defined) option is selected.
Figure 7-1. Send Data Payload Edit Parameter Dialog
Both the Current value and Default valuemay be displayed in text format or in hex format. You may edit, delete,
or add text to the value fields when the Textoption is selected. The file size is automatically adjusted to the pay-
load length.
When endpoint pairs with embedded payloads share the same destination port, the same script must be used.
Furthermore, only one CONNECT_INITIATE must exist within the script.
The total size of a script may not exceed 27,904 in the current release; use of embedded payloads can often
cause this limit to be exceeded.
In addition to typing (or pasting) in the value fields, you can also import data from a file. Press the appropriate
Import... button. The dialog in Figure 7-2 will be displayed.
Figure 7-2. Import Data Dialog
- 66 -
Use the Browse... button to locate the file to be imported. After you have located the file, press the Open button.
The contents of the file will be displayed in text or hex. It is not necessary to import the entire contents of the file.
You may specify an offset within the file and a size to import. Changing the offset will show data from the spe-
cified offset is displayed at the top of the window. Press OK to accept the file and file slice to import.
- 67 -
Specifying External Payload Files

The Payload file (user defined) option allows you to supply payload to the script using an external data file. This
section includes the following topics:
l External Payload File Overview
l Selecting an External Payload File
l Using Embedded Versus Reference Payload Data
l Referenced Payload File Considerations
l Saving a Script with Embedded or Referenced Payload Data
l Saving a Test with External Payload
l Exporting Tests with External Payload to Older Versions
External Payload File Overview

When you set a send_datatype parameter to Payload file (user defined) you must:
l specify the external file that contains the payload data, and
l choose whether to embed that file into the script or include a reference to the file from the script.
The Payload file (user defined) option is available for all IxChariot pair types that contain user-editable scripts:
regular pairs and multicast pairs. However, this option is not available for Video pairs and Hardware Per-
formance Pairs. For VoIP pairs, you specify payload data source using the Add a VoIP Endpoint Pair and Edit a
VoIP Endpoint Pair dialog boxes.
The Payload file (user defined) option overcomes the size restrictions associated with Embedded Payload Data
(Specifying Embedded Payload Data). And unlike Userxx.cmp files, you do not need to place a copy of your
payload files on every endpoint computer used in a test.
Selecting an External Payload File

To select an external payload file to use with a SEND command:
1. Open the script in the Script Editor.
2. Double-click the SEND command.
The Edit Parameter dialog opens (refer to Figure 7-3).
3. Choose Payload file (user defined) as the Current Value.
4. Click Browse to locate the payload file.
5. Choose either Embedded Payload Data or Referenced Payload File.
(Refer to Using Embedded Versus Reference Payload Data for a description of these two choices.)
6. Click OK.
Figure 7-3. shows an example of the Edit Parameter dialog for the send_datatype variable when the Payload
file (user defined) option is selected.
Figure 7-3. Edit Parameter Dialog for send_datatype
- 68 -
If you choose Embedded Payload Data and the payload file is 100 MB or larger, IxChariot displays the following
warning message:
The selected payload file is larger than 100 MB. The size
of an embedded payload file has a direct impact on the
script and test file size.
Do you want to continue?
If you choose Referenced Payload File, IxChariot displays the following warning message:
You are inserting a payload file by reference only.

Changes to referenced payload files, will impact
subsequent test runs, which may produce different
results. Are you sure you want to continue?
You can disable both of these warning messages.
Using Embedded Versus Reference Payload Data

You need to consider several factors when deciding whether to use embedded payload files or referenced pay-
load files. If you choose "embedded," the payload data is copied into and stored with the script. If you choose
"referenced," the script stores only a pointer to the externally-stored payload file. The following discussion
presents general guidelines.
Use embedded payload files if:
- 69 -
l The size of the payload data does not exceed 2 GB (2,147,483,647 bytes).
l You need to guarantee the integrity of the payload data used by a script, such that you can faithfully
reproduce tests in various test environments.
Use referenced payload files if:
l The size of the payload data exceeds 2 GB (2,147,483,647 bytes).
(Note that the combined size of all payload data for one endpoint cannot exceed 4 GB.)
l You modify the payload files quite often and want to avoid re-import the file into the script each time the
payload changes.
l You want to reduce the size of saved script and test files.
Referenced Payload File Considerations

The following are additional factors to consider when using referenced payload files:
l When using referenced payload files in a script, IxChariot stores only the file name plus certain file prop-
erties with the script.
l There are no restrictions on when and how payload files can be changed. Therefore, script file and test
file integrity is the responsibility of the user. IxChariot can detect, but cannot control, changes to the pay-
load files.
l Changes to referenced files take effect immediately upon the next test run.
l When using referenced payload files in a script, if you copy or move the script file or test file to another
machine, IxChariot does not copy or move the referenced payload files. It is the responsibility of the user
to transfer referenced payload files.
l Export of already-embedded payload files is not supported.
l You can use the same payload file in different scripts in the same test. For example, you can use a
single payload file to emulate multiple users accessing a Web server and retrieving the same inform-
ation.
Note: Embedded payload files are not really embedded until you save the script or the test. In other
words, until you save the script or the test, the payload file exists only in the original location and is sus-
ceptible to modifications.
Saving a Script with Embedded or Referenced Payload Data

When you save a script in which you have set a send_datatype parameter to Payload file (user defined),
IxChariot saves the SCR file and performs these actions:
l If you selected Embedded Payload Data, IxChariot saves the payload data with the script. If you selec-
ted Reference Payload File, IxChariot saves only a reference to the payload file.
l If the Save operation takes longer than three seconds, IxChariot displays a progress bar.
l When saving the script, IxChariot performs a check to detect if the payload file was changed after it was
added to the script. If the payload is embedded, this check is made only once, before the first save. If the
payload is referenced, this check is performed for each save.
IxChariot displays the following warning if it determines that a payload file has, indeed, been modified:
The payload file "%s" has been modified since it was inserted in the script. Do you want to continue this
operation?
l If the script includes referenced payload, IxChariot displays a warning message asking if you want to
save the payload as embedded data.
You can disable the warning messages.
Saving a Test with External Payload

If you create a test that uses a script in which you have set a send_datatype parameter to Payload file (user
defined), IxChariot takes the following actions when you save the test:
- 70 -
l If the Save operation takes longer than three seconds, IxChariot displays a progress bar.
l If you selected Embedded Payload Data for one or more SEND commands, IxChariot saves the pay-
load data with the test. A single payload file used by multiple scripts within the test is stored only once.
(Depending on the size of the embedded payload files, this process can take a significant amount of
time and disk space.)
l If you selected Reference Payload File for one or more SEND commands, IxChariot stores only a ref-
erence to the payload files.
l When saving the test, IxChariot performs a check to detect if any payload files were changed outside of
IxChariot. If IxChariot detects any modified files, it displays a warning that lists the modified files. This
check is performed for both embedded and referenced payload files.
Exporting Tests with External Payload to Older Versions

If you have a test that contains one or more scripts in which you have set a send_datatype parameter to Pay-
load file (user defined), and you save the test to an older version of IxChariot (6.10 or earlier), IxChariot per-
forms these actions:
l Saves the test file, removing any embedded payload data and removing any references to referenced
payload files.
l Converts all Payload File send_data_types to NO_COMPRESS data types in the scripts.
- 71 -
Chapter 8: IxChariot Application Groups

This chapter provides a complete description of IxChariot application groups: what they are, how they are used,
and how to create them. IxChariot application groups enable synchronized pair testing: tests that use multiple,
interacting scripts.
l Synchronized Pair Testing
l Creating and Running Synchronized Pair Tests
l Creating and Managing Application Groups
l Adding Synchronization Commands to Scripts
l Creating Synchronization Tests for VoIP Pairs
- 72 -
Synchronized Pair Testing

Topics in this section:
l Introduction to Synchronized Pair Testing
l Types of Pairs Supported
l How Synchronization is Achieved
l How Synchronization is Achieved
l How Wait Times Are Recorded in Timing Records
- 73 -
Introduction to Synchronized Pair Testing
IxChariot provides the means to design tests that emulate applications that employ multiple connections. For
example, FTP operations require two connections: one for control (port 21) and the other for data transmission
(port 20). Another example is an Internet chat application, in which multiple participants join and leave the chat
session independent of one another.
To emulate applications such as FTP and internet chat clients, you can define tests with multiple pairs that:
l Start and stop independent of one another.
l Are logically linked, such that an event in one connection triggers the suspension or resumption of exe-
cution in another connection.
Tests of this nature are referred to as synchronized pair tests.
- 74 -
Types of Pairs Supported
You can create synchronized pair tests for the following types of endpoint pairs:
l Regular pairs (using streaming or nonstreaming scripts).
l VoIP pairs.
Hardware performance pairs, VoIP hardware performance pairs, video pairs, video multicast, and multicast
pairs are not supported by the Pair Synchronization feature.
Most of the topics in this section of the manual apply to both types of pairs, with the following exceptions:
l Refer to Adding Synchronization Commands to Scripts for information that is specific to scripts used by
regular pairs.
l Refer to Creating Synchronization Tests for VoIP Pairs for instructions that are specific to VoIP pairs.
- 75 -
How Synchronization is Achieved
Synchronizing the operations of two or more scripts requires that the scripts recognize and respond to events
that are common to both scripts. The use of such events requires a test definition that includes the following ele-
ments.
Application Groups
An Application Group is a grouping of pairs that will participate in a synchronized test. In addition to identifying
the participants of a synchronized test, the application group also defines the synchronization events used in
the test. An application Group can use a maximum of 1,000 events.
Synchronization Commands
These are the two script commands that enable the synchronization of actions across multiple pairs:
l WAIT_EVENT
When an IxChariot script encounters a WAIT_EVENT command, it pauses execution while it waits for a
specific event to occur. The script will not continue execution until it receives a SIGNAL_EVENT com-
mand from another script for that same event.
l SIGNAL_EVENT
When a script executes a WAIT_EVENT command, it listens for a SIGNAL_EVENT command for the
same event. It resumes execution of the script once it receives that SIGNAL_EVENT command from one
of the other pairs defined in the application group.
Events
Events are objects defined within application groups and passed as parameters by the WAIT_EVENT and
SIGNAL_EVENT commands. An event is simply a unique name (a character string) defined within an applic-
ation group. An event does not specify any actions. Rather, it acts as a token to trigger the scripts to pause or
resume execution at specific points in the scripts. Each event can be associated with one and only one WAIT_
EVENT command, whereas a single event can be used by more than one SIGNAL_EVENT commands.
Using meaningful names for your events can make your scripts much easier to read. For example, FTP scripts
might use events such as "login_complete" and "start_file_transfer."
- 76 -
Application Groups Delivered with IxChariot
IxChariot provides a set of prebuilt application groups, each of which emulates an application that employs mul-
tiple connections. These files are located in the following folders:
C:\Program Files\Ixia\IxChariot\Application Groups\ C:\Program Files\Ixia\IxChariot\Scripts\Gaming\

Refer to the IxChariot Scripts and Streams Reference Guide for detailed information about these application
groups.
- 77 -
How Wait Times Are Recorded in Timing Records
Wait times are accounted for in timing records based on three factors:
l Whether the script is streaming or nonstreaming.
l The placement of the WAIT_EVENT command within a script.
l The WAIT_EVENT command's Type parameter.
These are described in the subsections that follow.
The Type Parameter

The WAIT_EVENT command takes two parameters:
WAIT_EVENT(Event, Type)
The Event parameter specifies the name of an event, as described in Events. The Type parameter can be
either of the following values:
l Measured Specifies that the wait time will be measured. A measured WAIT_EVENT can be located on
either Endpoint1 or on Endpoint2.
l Not-Measured Specifies that the wait time will not be measured. An unmeasured WAIT_EVENT can be
located only on Endpoint1.
Wait Times in Nonstreaming Scripts

For nonstreaming scripts, the placement of the WAIT_EVENT commands and the value of the Type parameter
determine how the wait times are recorded in the timing records, as described in Table 8-1.
Table 8-1. How Wait Times Are Recorded for Nonstreaming Scripts
If the WAIT_EVENT command is And the Type

Then the wait time will be recorded as:
... Parameter is ...
inside a pair of START_TIMER and "Not-Measured" Inactive Time in the timing records.
END_TIMER commands, "Measured" Measured Time in the timing records.
outside a pair of START_TIMER Inactive Time for the first timing record. In this case,
Either value
and END_TIMER commands, behavior is similar to a SLEEP command.
A measured WAIT_EVENT command may be necessary to reflect the behavior of a simulated application pro-
tocol (if the protocol implies wait times that need to be measured). An unmeasured WAIT_EVENT may be neces-
sary when a script must wait in transaction loops while the pairs are synchronized (the only way that IxChariot
can synchronize pairs is to use WAIT_EVENT commands).
Wait Times in Streaming Scripts

A streaming pair (including VoIP) can have any number of WAIT_EVENT commands on Endpoint1, and these
commands can appear anywhere in the script. (However, because streaming is unidirectional from Endpoint1
to Endpoint2 WAIT_EVENT commands cannot be added on Endpoint2.)
The wait times are measured as follows:
l If the WAIT_EVENT is unmeasured (the Type parameter is "Not-measured"), the wait time will not be
measured on Endpoint2. The test timer on Endpoint2 will be started after the WAIT_EVENT is com-
pleted. In other words, the behavior will be as if there is no WAIT_EVENT command and initial delay is
0.
l If the WAIT_EVENT is measured (the Type parameter is "Measured"), the wait time will be measured on
Endpoint2 as inactive time for the first timing record. This is because the test timer will be started before
the WAIT_EVENT command, while the timing record timer will be started as usual on the START_TIMER
- 78 -
command in the script. The behavior is as if there is no WAIT_EVENT command, but the initial_delay is
a non-zero value. With WAIT_EVENT and initial_delay both greater than 0, the inactive time for the first
timing record will be the sum of the wait time and sleep time.
The unmeasured WAIT_EVENT has an additional advantage. For an unmeasured WAIT_EVENT, the timer on
Endpoint2 is started only after the WAIT_EVENT, so there is no fear of getting a timeout error because of an
unusually long wait time.
- 79 -
Creating and Running Synchronized Pair Tests

This section describes how to create and run tests that use application groups.
l Creating a Test from an Application Group
l Application Group Validation
l Error Conditions in Application Group Tests
- 80 -
Creating a Test from an Application Group
The procedure for creating a synchronized pair test differs from that of tests using individual (non-synchronized)
pairs.
Unlike individual scripts which you select as part of a test definition you must first import an application group
into a test window. Once you have done that, the procedures for creating the test are identical to any other test.
Importing an Application Group

To import an application group into a Test window:
1. Select File > ApplicationGroup > Import.
2. Select the desired application group file (.iag file).
3. Click Import.
Creating and Saving the Test

Once you import an application group into a Test window, the remaining procedures are the same as those of
any other type of test. Typically, you will perform these actions to create and execute your test:
1. Assign ports to the endpoint pairs.
The application groups provided with IxChariot use symbolic names for the endpoints. For example, the
SIP-VoIP application group uses endpoints names such as caller and callee. You need to replace those
with actual endpoint addresses.
2. Make any desired modifications to the test scripts (such as modifying script variables).
3. Execute the test.
4. Save the test.
IxChariot saves the test as a .tst file.
- 81 -
Application Group Validation
Running an application group test is no different from running any other type of test. However, when you start
the run of a test that includes application groups, IxChariot performs a set of validations before executing the
test. These validations include:
l Checking the script for consistency, including:
l Verifying that each pair contains at least one synchronization command.
l Verifying that each event is referenced by a maximum of one WAIT_EVENT command.
l Verifying that each WAIT_EVENT command has at least one corresponding SIGNAL_EVENT
command (the commands reference the same event).
l Checking for deadlock conditions.
Deadlock is a condition that occurs when two processes are each waiting for the other to complete
before proceeding. Deadlock can occur in an IxChariot script if two scripts each execute a WAIT_EVENT
command before either script has executed a corresponding SIGNAL_EVENT. In this case, neither
script could resume execution.
Deadlock can also occur when WAIT_EVENT and SIGNAL_EVENT commands execute within loops.
For example, assume that an application group includes scripts that use event event1 as follows:
l A WAIT_EVENT(event1) command occurs in a loop having p iterations.
l A SIGNAL_EVENT(event1) command occurs in a loop having n iterations.
l A SIGNAL_EVENT(event1) command occurs in a loop having m iterations.
Because a SIGNAL_EVENT command will resume a referred WAIT_EVENT command only
once, a deadline condition will occur if p>m+n.
Before executing a test, you can validate the application group to check for potential problems. Refer to Val-
idating an Application Group for instructions.
- 82 -
Error Conditions in Application Group Tests
In tests that use application groups, an event in one pair triggers the suspension or resumption of a script in
another pair. Dependencies among pairs are therefore inherent in application groups.
Because application groups define dependencies among separate pairs, IxChariot must ensure that the failure
of one pair during a test will not cause a deadlock condition in any of the other pairs. For example, if script_b is
waiting for script_a to signal an event, and script_a fails before the event is signaled, IxChariot must ensure that
script_b does not wait indefinitely for that event. Therefore, if one pair in an application group test fails, the other
pairs in the test will ignore all WAIT_EVENT and SIGNAL_EVENT messages associated with the failed pair.
This allows the test to continue to run.
- 83 -
Creating and Managing Application Groups

l The Application Group Submenu
l Creating an Application Group
l Editing an Application Group
l Adding Events to an Application Group
l Deleting an Application Group
l Copying and Pasting an Application Group
l Renaming an Application Group
l Adding Pairs to an Existing Application Group
l Removing Pairs from an Application Group
l Replacing Host Addresses in an Application Group
l Validating an Application Group
l Exporting an Application Group to a File
l Importing an Application Group from a File
- 84 -
The Application Group Submenu
A test using synchronized pairs requires an application group. You create and manage application groups
using the following IxChariot menus:
l The Application Group submenu selected from the File menu (for importing and exporting application
groups).
l The Application Group submenu selected from the Edit menu.
l The Application Group pop-up menu that is available when you select one or more pairs and right-click
the mouse.
Figure 8-1 shows an example of the Application Group submenu accessed from the Edit menu.
Figure 8-1. Application Group Menu
- 85 -
Creating an Application Group
To create a new application group, follow these steps:

1. Select one or more pairs in the Tests window.
2. Right-click the mouse to display the pop-up menu.
3. Select Add to Application Group... from the Application Group item on the menu.
IxChariot opens the Add Pair(s) to Application Group dialog (see Figure 8-2).
Figure 8-2. Add to Application Group Dialog
4. Select Add to new application group.

5. Enter a name for the application group in the Name field.
The name can be a maximum of 25 characters in length.
6. Tab to the Comment field and enter a comment (optional).
The comment can be a maximum of 128 characters in length.
7. Tab to the Name field in the Event List section of the dialog.
8. Add one or more events for this application group:
- 86 -
a. Type a Name for the event.

Event names must be unique within an application group.
b. Tab to the Comment field and add a comment for the event (optional).
c. Click ADD to add the event to the list.
d. Repeat these steps for each event for this application group.
9. Click OK.
IxChariot closes the Add to Application Group dialog.
10. To display the application group name in the Group column, click the PG button.
Once you have defined an application group, you may want to validate it (check for errors) and export it to a disk
file. These activities are described in the following topics:
l Validating an Application Group.
l Exporting an Application Group to a File (to save the application group for future test runs).
Having created a valid application group, the next step is to create or modify IxChariot scripts that use that
application group in testing:
l For regular pairs, this is described in Adding Synchronization Commands to Scripts.
l For VoIP pairs, you do not edit the scripts directly. The procedure for specifying the events is described
in Creating Synchronization Tests for VoIP Pairs.
- 87 -
Editing an Application Group
To make modifications to an application group, follow these steps:

1. Click the PG button to display the application group names in the Group column of the Test window.
2. Select the application group that you need to edit.
4. Select Edit Application Group... from the Application Group item on the menu.
IxChariot opens the Edit Application Group dialog.
5. Select the application group from the Application Group to Edit list.
6. Make the desired modifications and additions.
7. Click OK.
IxChariot closes the Edit Application Group dialog.
- 88 -
Adding Events to an Application Group
To add events to an application group, follow these steps:

2. Select the application group to which you want to add events.
4. Select Edit Application Group... from the Application Group item on the menu.
IxChariot opens the Edit Application Group dialog.
5. Add the events for this application group:
a. Tab to the Name field in the Event List section of the dialog.
b. Type a Name for the event.
c. Tab to the Comment field and add a comment (optional).
d. Click ADD to add the event to the list.
e. Repeat these steps for each event.
6. Click OK.
IxChariot closes the Edit Application Group dialog.
- 89 -
Deleting an Application Group
To delete an application group and all the pairs contained in the group, follow these steps:
2. Select the application group that you want to delete.
4. Select Delete Application Group... from the Application Group item on the menu.
IxChariot displays a confirmation dialog: "Are you sure you want to delete the application group and its
pairs?"
5. Click YES.
IxChariot deletes the application group and all the pairs contained within the group.
Note: If you want to retain one or more of the pairs contained in an application group, remove those pairs
before deleting the group. Refer to Removing Pairs from an Application Group for instructions.
- 90 -
Copying and Pasting an Application Group
To copy and paste an application group, follow these steps:

1. Select the application group that you want to copy.
3. Select "Copy Application Group..." from the Application Group item on the menu.
IxChariot copies the application group to the clipboard.
4. Select "Paste Application Group..." from the Application Group item on the Edit menu.
IxChariot opens the Rename application group dialog, which contains the name of the application
group that was copied to the clipboard (refer to Renaming an Application Group).
5. Enter a new name for the application group.
6. Click OK.
IxChariot creates the new application group.
- 91 -
Renaming an Application Group
You will need to rename an application group whenever you perform either of the following tasks:
l Copy and paste an application group (see Copying and Pasting an Application Group).
If you copy an application group to the clipboard and then attempt to paste it into the Test window,
IxChariot requires you to assign a unique name to the group that you are pasting.
l Importing an application group (see Importing an Application Group from a File).
If you have an application group open and you attempt to import an application group with the same
name, IxChariot requires that you to assign a unique name to the group that you are importing.
In each case, IxChariot opens the Rename an Application Group dialog, as shown in Figure 8-3.
Figure 8-3. Rename Application Group Dialog
To complete the paste or import operation, you must:

1. Enter a unique name for the application group.
2. Click OK.
- 92 -
Adding Pairs to an Existing Application Group
To add one or more pairs to an existing application group, follow these steps:
1. Select the pair(s) that you want to add to the application group.
3. Select Add to Application Group... from the Application Group item on the menu.
IxChariot opens the Add Pair(s) to Application Group dialog.
4. Select the application group to which you are adding the pair(s).
5. Click OK.
IxChariot adds the pairs to the application group.
Note: You can also replicate pairs within an application group. However, this is not recommended because
you may end up replicating scripts which can result in multiple WAIT_EVENT commands that reference the
same event.
- 93 -
Removing Pairs from an Application Group
To remove one or more pairs from an application group, follow these steps:
2. Expand the list of pairs for the desired application group.
3. Select the pairs (one or more) that you want to remove from the group.
5. Select Remove from Application Group... from the Application Group item on the menu.
IxChariot removes the selected pairs from the application group and moves them to "No Group."
Note that if you remove all the pairs from an application group, IxChariot deletes the application group.
- 94 -
Replacing Host Addresses in an Application Group
The application groups delivered with IxChariot (as well as those that you create with IxProfile) use symbolic
names for the endpoints in the group. For example, the SIP-VoIP application group uses endpoint names such
as caller and callee. Therefore, when you import one of these application group, you need to replace the sym-
bolic names with the actual addresses that you are using in your test. IxChariot provides the Search and
Replace Addresses dialog for this purpose.
To search for and replace addresses in an application group, follow these steps:
2. Select the desired application group.
4. Select Search and Replace Addresses... from the Application Group item on the menu.
IxChariot opens the Search and Replace Addresses dialog. Test addresses and management
addresses are listed separately.
5. Select an address that you want to replace (a test or a management address).
6. Click Modify.
IxChariot opens the Change Address dialog.
7. Enter the replacement address.
8. Click OK to close the Change Address dialog.
9. Click OK to close the Search and Replace Addresses dialog.
IxChariot locates each instance of the address and replaces it with the new address that you entered. The
replacement is made in each of the pairs contained in the application group.
- 95 -
Validating an Application Group
To verify the validity of an application group, follow these steps:

2. Select the application group that you want to validate.
4. Select Validate Application Group... from the Application Group item on the menu.
IxChariot validates the application group, displaying a status bar as it progresses. Once the validation is com-
plete, it displays a dialog that describes the results of the validation. The validation checks for:
l Application group script consistency.
l Deadlock checking.
The same validation check is automatically performed when you run a test using an application group. Refer to
Creating and Running Synchronized Pair Tests for more information.
- 96 -
Exporting an Application Group to a File
IxChariot allows you to save (export) application groups as files on disk and reload them whenever desired. To
export an application group to a file, follow these steps:
2. Select the application group that you want to export.
3. Select Export... from the Application Group item on the File menu.
IxChariot opens the Export an Application Group dialog.
4. Specify the desired folder in the Save in field.
5. Enter a file name.
6. Click EXPORT.
IxChariot exports the application group to a file, giving it a file extension of .iag.
- 97 -
Importing an Application Group from a File
IxChariot allows you to load (import) an application group that was previously saved to an .iag file. To import an
application group, follow these steps:
1. Select Import... from the Application Group item on the File menu.
IxChariot opens the Import an Application Group File dialog.
2. Select the file name (application groups have an .iag file extension).
3. Click IMPORT.
IxChariot imports the application group into the Test window.
- 98 -
Adding Synchronization Commands to Scripts

l Test Requirements
l Rules for Writing Scripts for Application Groups
l Editing Scripts to Add Synchronization Commands
l Creating Synchronization Tests for VoIP Pairs
This section describes the procedure to add synchronization commands to scripts, and also provides some
basic rules for writing scripts for such tests. Note that this section is specific to regular pairs. For information
about VoIP scripts, refer to Creating Synchronization Tests for VoIP Pairs.
- 99 -
Test Requirements
Running a test using synchronized pairs requires two basic elements:

l A valid application group that defines the synchronization events for the test and identifies the pairs that
belong to the group.
l A valid script for each pair in the application group. Typically, a script that is used by an application
group will contain at least one WAIT_EVENT or SIGNAL_EVENT command. However, this is not a
requirement; it is possible to include pairs that are not involved in the synchronization events.
- 100 -
Rules for Writing Scripts for Application Groups
When writing scripts for use in application groups, you must observe the following rules:
l A WAIT_EVENT command must have at least by one corresponding SIGNAL_EVENT command and
this SIGNAL_EVENT command must be executed on the same machine as the WAIT_EVENT.
l Each event can be referenced by a maximum of one WAIT_EVENT command. (However, an event can
be referenced by more than one SIGNAL_EVENT command.)
l A WAIT_EVENT command should be following by a SEND or a CONNECT_ INITIATE command. This
ensures that the other endpoint will execute a blocking command, such as RECEIVE or CONNECT_
ACCEPT.
l For nonstreaming scripts, a measured WAIT_EVENT can be located on either Endpoint1 or on
Endpoint2. An unmeasured WAIT_EVENT can be located only on Endpoint1.
- 101 -
Editing Scripts to Add Synchronization Commands
To add synchronization commands to a script, follow these steps:

1. Edit the script.
2. Move to the line beneath which you want to insert a WAIT_EVENT or SIGNAL_EVENT command.
3. Select the desired command from the Insert menu. The four selections are Wait at Endpoint1, Wait at
Endpoint2, Signal at Endpoint1, and Signal at Endpoint2.
IxChariot opens the Edit Parameter dialog.
4. Select Synchronization Wait Event (or Synchronization Signal Event) from the Parameter drop-down
box.
Note that the Variable name is sync_event.
5. Select an event for the Current Value from the Event drop-down box.
Your choices will be "Not Assigned" plus any events that you have defined for the current application
group, as shown in Figure 8-4.
Figure 8-4. Synchronization Wait Event Parameter
6. If you are inserting a WAIT_EVENT command, select Synchronization Wait Type from the Parameter
drop-down box, then select one of the choices for the Current Value. (This parameter is not required by
the SIGNAL_EVENT command.)
Your select determines whether or not the wait time will be measured.
7. Click OK.
IxChariot inserts the command, followed by its parameter(s), into the script.
- 102 -
Synchronization Commands Example
The example in Figure 8-5 shows two scripts using the event "login_complete" to control the pause and resump-
tion of processing. Script-A pauses when it executes the WAIT_EVENT command. While waiting, it listens for a
SIGNAL_EVENT for "login_complete." When Script-B executes the SIGNAL_EVENT command, it causes any
other script waiting on that event to resume processing.
Figure 8-5. Synchronization Commands in Script Editor
Figure 8-6 shows an example of two synchronized scripts used in an application group. In this example, Pair_
1_A_B pauses when it reaches the WAIT_EVENT command on line 8. It does not resume execution until
another script in the application group (Pair_3_A_B in this example) executes a SIGNAL_EVENT command for
the same event. In this case, the event name is "event_3_P3_P1_A."
Figure 8-6. Synchronization Commands in the Script Editor
- 103 -
- 104 -
Creating Synchronization Tests for VoIP Pairs

IxChariot supports synchronized pair testing for:
l Regular pairs.
l VoIP pairs.
This section describes how set up a VoIP pair for use in a synchronization test. By combining VoIP pairs and
regular pairs that use Voice Signaling scripts (H.323 or SIP), you can simulate realistic VoIP scenarios (see the
SIP_VoIP.iag application group for an example).
l Location of Wait and Signal Commands in Streaming Scripts
l Creating a Synchronized Test for VoIP Pairs
l Adding Synchronization Commands to Scripts
- 105 -
Location of Wait and Signal Commands in Streaming Scripts
A streaming pair (including VoIP) can have:

l Any number of WAIT_EVENT commands on Endpoint 1. These commands can appear anywhere in the
script. However, because streaming is unidirectional (from Endpoint 1 to Endpoint 2), WAIT_EVENT
commands cannot be added on Endpoint 2.
l Any number of SIGNAL_EVENT commands on Endpoint 1 and Endpoint 2. These commands can
appear anywhere in the script.
- 106 -
Creating a Synchronized Test for VoIP Pairs
To create a test using synchronized VoIP pairs, follow these steps.

1. Create the VoIP pairs that will be used in the test.
2. Create an application group and add the VoIP pairs to that group.
Instructions for creating an application group are provided in Creating and Managing Application
Groups.
3. Select the first VoIP pair in the application group, right-click the mouse, then select Edit.
4. Click the Synchronization button on the Edit a VoIP Endpoint Pair dialog.
IxChariot expands the dialog, as shown in Figure 8-7.
Figure 8-7. Synchronization Fields for VoIP Endpoints
5. Specify the Endpoint 1 pair synchronization events:

a. Select the Wait until checkbox, then choose an event from the drop-down list.
Your choices will be Not Assigned plus any events that you have defined for the current applic-
ation group.
- 107 -
a. Check the Count wait time as inactive time in results if appropriate for your test.
a. Select the Signal checkbox, then choose an event from the drop-down list.
Your choices will be Not Assigned plus any events that you have defined for the current applic-
ation group.
6. Specify the Endpoint 2 pair synchronization events:
Select the Signal checkbox, then choose an event from the drop-down list.
Your choices will be Not Assigned plus any events that you have defined for the current application
group.
7. Click OK.
8. Repeat steps 4 through 7 for each VoIP pair in the application group.
- 108 -
Appendix A: Mapping Communication

Commands to APIs
This appendix describes the mapping of IxChariot communication commands to the APIs on the endpoint com-
puters.
The IxChariot script commands that control endpoint communications (such as CONNECT_INITIATE) are inde-
pendent of the network protocol on which the script is running. However, they are mapped to API calls at the
endpoints. The mappings of commands to API calls are describes in the following topics:
l Mapping of Script Commands for Sockets
l Mapping of Script Commands for TLI
Refer to the following topics for related information:

l Appendix B, Default Buffer Sizes for IxChariot Scripts
l Communication Commands
l Setting the SEND Data Type
l SEND Command Payload Options
- 109 -
Mapping of Script Commands for Sockets

The Sockets programming interface is used for the TCP and UDP protocols on all platforms, as well as for the
IPX and SPX protocols on the Windows platforms. Table A-1 describes the mapping of IxChariot com-
munication script commands to the Sockets API.
Table A-1. Mapping of Script Commands to the Sockets API
Script Com- Sockets Datagram (for IPX and
Sockets Stream (for SPX and TCP)
mand UDP)
CONNECT_
INITIATE socket()
Socket() bind() and connect(): once
(source_port, bind()
per connection, per test.
send_buffer, connect()
receive_buffer)
CONNECT_
socket()
ACCEPT (des-
bind()
tination_port, None.
listen()
send_buffer,
accept()
receive_buffer)
Using sendto() or send(), send the
number of bytes in size, in send_buf-
SEND (size,
Using write(), send the number of bytes in size, in fer_size chunks. The last buffer may
send_buffer_
send_buffer_size chunks. The last buffer may be be smaller than the send_buffer_
size, send_data-
smaller than the buffer_size. The maximum buffer_ size.
type, send_data_
size value is 2,147,483,647. See Sockets Datagram send_buffer_
rate)
size for information on the maximum
buffer size.
Issue read() calls in a loop, until the number of Issue recvfrom() or recv() calls in a
bytes specified in size have been received, in loop, until the number of bytes spe-
RECEIVE (size,
receive_buffer_size chunks. The last buffer cified in size have been received.
receive_buffer_
received may be smaller than the receive_buffer_ See Sockets Datagram receive_buf-
size)
size value. The maximum buffer_size value is fer_size for information on the max-
2,147,483,647. imum buffer size.
Issue sendto() or send() to return a

A one-byte data record is returned to the partner one-byte data record to the partner
CONFIRM_ endpoint that issued the CONFIRM_REQUEST. endpoint that issued the CONFIRM_
ACKNOWLEDGE This byte is counted in the summary of bytes sent REQUEST. This byte is counted in
or received. the summary of bytes sent or
received.
close(): once per connection at end

DISCONNECT close()
of a test.
Notes for Table A-1

The following notes apply to Table A-1.
Sockets Datagram send_buffer_size

The maximum value for the send_buffer_size of the SEND command depends on the platform and network pro-
tocol stack. Most stacks that we have tested support sending UDP or RTP datagrams of around 65,000 bytes.
For IPX tests, the maximum value for the buffer size is limited by the network packet size.
- 110 -
Sockets Datagram receive_buffer_size

When recvfrom() or recv() is used, the endpoint uses a buffer whose size is the maximum value of receive_buf-
fer_size, so that it can receive any buffer at any time. This is necessary because datagrams can be received out
of sequence; an endpoint must be able to receive a large datagram (such as a retransmitted or delayed data-
gram) when only a small one is expected. Although the specified receive_buffer_size is not used with recvfrom
() or recv(), it is used to calculate the window size in numbers of datagrams. Therefore, it is important to use the
same value for the receive_buffer_size as for the send_buffer_size. The maximum value for the receive_buffer_
size of the RECEIVE command depends on the platform and network protocol stack.
- 111 -
Mapping of Script Commands for TLI

The TLI programming interface is used for the IPX and SPX protocols. The same port number is required for all
the CONNECT_INITIATE commands in a script. Table A-2 describes the mapping of IxChariot communication
script commands to the TLI API.
Table A-2. Mapping of Script Commands to the TLI API
Script Com-
TLI Stream (for SPX) TLI Datagram (for IPX)
mands
CONNECT_
INITIATE t_open() t_open()
(source_port, t_bind() t_bind() and t_connect(): once per
send_buffer, t_connect() connection, per test
receive_buffer)
CONNECT_
ACCEPT (des-
t_listen()
tination_port, None.
t_accept()
send_buffer,
receive_buffer)
SEND (size,
send_buffer_
Using t_sndudata(), send the number
size, send_data-
of bytes in size, in buffer_size chunks.
type, send_data_ Using t_snd(), send the number of bytes in size, in
The last buffer may be smaller than
rate) send_buffer_size chunks. The last buffer may be
the send_buffer_size.
Refer to Provid- smaller than the send_buffer_size. The maximum
See TLI Datagram send_buffer_size
ing Script Pay- send_buffer_size value is 32767.
below for information on the max-
load for more on
imum buffer size.
the datatype para-
meter.
Issue t_rcvudata() calls in a loop, until

Issue t_rcv() calls in a loop, until the number of
the number of bytes specified have
RECEIVE (size, bytes specified in size have been received, in
been received.
receive_buffer_ receive_buffer_size chunks. The last buffer
See TLI Datagram receive_buffer_
size) received may be smaller than the buffer_size
size below for information on the max-
value. The maximum buffer_size value is 32767.
imum buffer size.
Issue t_sndudata() to return a one-

Issue t_snd() to return a one-byte data record to
byte data record to the partner end-
CONFIRM_ the partner endpoint which issued the CONFIRM_
point which issued the CONFIRM_
ACKNOWLEDGE REQUEST. This byte is counted in the summary of
REQUEST. This byte is counted in the
bytes sent or received.
summary of bytes sent or received.
Notes for Table A-2

The following notes apply to Table A-2.
TLI Datagram send_buffer_size

The maximum value for the buffer_size of the SEND command is limited by the IPX network packet size.
TLI Datagram receive_buffer_size

When t_rcvdata() is used, the endpoint uses a buffer whose size is the maximum value of c, so that it can
receive any buffer at any time. This is necessary because datagrams can be received out of sequence; an end-
point has to be able to receive a large datagram (for example, a retransmitted or delayed datagram) when only
a small one was expected. Although the specified buffer_size is not used with c, it is used to calculate the win-
- 112 -
dow size in numbers of datagrams. Therefore, it is important to use the same value for the RECEIVE buffer_size
as for the send_buffer_size.
The maximum value for the buffer_size of the RECEIVE command is limited by the IPX network packet size.
- 113 -
Appendix B: Default Buffer Sizes for

IxChariot Scripts
In IxChariot scripts, the keyword DEFAULT instructs the endpoint to use the default buffer size for the protocol
and platform on which the Performance Endpoint is running.
The default values, in bytes, are shown in the following table:
Operating Sys- TCP send/re- SPX send/re- UDP send/ IPX send/re- RTP send/re-
tem ceive ceive receive ceive ceive
Linux (all) 32,767 n/a 8,175 n/a 8,180
Macintosh 32,767 n/a 8,175 n/a 8,180

UNIX (all) 32,767 n/a 8,175 n/a 8,180
Windows 2000 32,767 32,767 8,175 1,383 8,180
Windows 2003 32,767 32,767 8,175 1,383 8,180
Windows CE 32,767 n/a 8,175 n/a 8,180
Windows Vista 32,767 32,767 8,175 1,383 8,180
Windows XP 32,767 32,767 8,175 1,383 8,180
- 114 -
validating 82, 96
Index wait times 78
WAIT_EVENT command 44, 76
A
Application Script Name 19
application commands 39
application scripts, See scripts 3
application groups
AUTO 34, 48
about 72
adding pairs to 93 B
Application Group menus 85 Basic Long Connection template 19
copying 91 Basic Short Connection template 19
creating 86 buffer size 53
creating tests from 80 editing 53
deadlock conditions 82 random 21
defining events in 86, 89 randomizing 54
deleting 90 receive 34-36
editing 88 send 34-36
events 76 buffers, default values 114
exporting 97
C
for VoIP pairs 105
Calgary Corpus data files 61, 63
host addresses, replacing 95
Calgary Corpus Web site 63
importing 81, 98
cmp files 61
removing pairs from 94
commands
renaming 92
application 39
rules for scripts 101
communication 34
SIGNAL_EVENT command 44, 76
program control 42
synchronization 76
commands, inserting in a script 29
synchronization commands 99
communication commands 34, 109
synchronized pair testing 73
CONFIRM_ACKNOWLEDGE 37
Type parameter 78
CONFIRM_REQUEST 36
- 115 -
CONNECT_ACCEPT 6, 35 WAIT_EVENT 44
CONNECT_INITIATE 6, 34 events, in applicaton groups 76
Current Value 15, 47 exponential distribution 58
external payload files 68
D
data rate optimization 51 H
datatype files 52 host addresses in application groups 95
datatype, send options 61
I
DEFAULT buffer size 114
INCREMENT_TRANSACTION 5, 43
Default Value 16, 47
initial_delay variable 55
delayed ACK algorithm 21
IxProfile 3, 95
destination port number 35, 48
DISCONNECT 6, 37 L
distributions 57 large payload files 68

lena.cmp 63
E
long versus short scripts 20
edit
LOOP 5-6, 42
script command parameters 13
script for multiple pairs 8 M
script variables 15 maximum number of commands 6
scripts 7 maximum segment size 21, 25, 29, 39
embedded payload data 66, 68 Move Down 28
Empty template 19 Move Up 28
END_LOOP 5-6, 42 MSS, See maximum segment size 21
END_TIMER 5, 43 multiple pairs, editing a script 8
event N
SIGNAL_EVENT 44 Nagle algorithm 21, 39
- 116 of 119-
NetWare programs 112 RFC 896 21

news.cmp 63 RTP Payload Types 40
NOCOMPRESS 62 RTP_PAYLOAD_TYPE 5, 40
nonstreaming scripts 3-4
S
normal distribution 57
Save to File 11, 27
O Save to Pair 11, 27
OPTION 21, 23, 39 script commands
OS/2 programs 112 application 39
communication 34
P
deleting 17
payload
inserting 17
embedded 61, 66
inserting, example 17
externally-referenced 61, 68
mapping to API calls 109
files 68
moving 17
user-defined 61, 68
program control 42
Poisson distribution 58
Sockets 110
port number 48
TLI 112
program control commands 42
Script Editor
R accessing 8
random buffer sizes 53 adding a new script 19
random SLEEP times 55 Edit menu 28
RECEIVE 6, 36, 53 editing parameters 13
RECEIVE command 53, 110, 112 editing variables 15
random buffer sizes 53 File menu 27
Redo 28 Insert menu 29
referenced payload files 68 inserting script commands 29
required commands 4-5 overview 7
RFC 768 22, 29, 39 saving 11, 27
- 117 -
script templates 19 structure of 4

shortcut keys 32 variable 14-15
toolbar 31 SEND 6, 35, 50, 52-53
script templates SEND command 52-53
basic long connection 19 buffer size 53
basic short connection 19 datatypes 52
empty 19 parameters for 53
streaming 19 random buffer sizes 53
scripts send data rate 50
about 3 send_datatype 61
adding, moving, deleting shortcut keys
commands 17
Script Editor 32
constant 13
SIGNAL_EVENT 44, 76, 100, 103
creating 19
SLEEP 6, 39, 55
current value 15, 47
SLEEP times 55
default value 16, 47
exponential distribution 58
defined 3
normal distribution 57
editing 7
Poisson distribution 58
file storage 3, 11
uniform distribution 57
long versus short 20
Sockets 110
maximum number of commands 6
Accept() call 110
nonstreaming 3-4
Bind() call 110
parameter 13
Close() call 110
required commands 4-5
Connect() call 110
rules for variables 47
Listen() call 110
saving 11, 27
mapping of script commands 110
streaming 3, 5
- 118 of 119-
Socket() call 110 U

source port 34, 48 UDP checksum 39
setting 48 and VoIP pairs 23
SPX disabling 23
choosing a port number 48 UDP, RFC 768 compliant 22
START_TIMER 5-6, 42 Undo 28
streaming script template 19 uniform distribution 57
streaming scripts 3, 5 UNLIMITED 50
template 19 Userxx.cmp files 64
Swap Sides 28
V
synchronized pair testing 3, 73
variable rules 47
T variables, Current versus Default value 47
TCP VoIP pairs, in application groups 105
delayed acknowledgment algorithm 21
W
sliding window 35
WAIT_EVENT 44, 76, 78, 100, 103
TCP_NODELAY 21
technical support 2 Z
TLI 112 ZEROS 62
mapping of script commands 112

t_bind() call 112
t_connect() call 112
t_open() call 112
t_rcv() call 112
t_rcvudata() call 112
t_snd() call 112
t_sndudata() call 112
trans.cmp 63
transmit MSS 21, 25, 29
- 119 -

Scripts Development

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Scripts Development

Încărcat de

Drepturi de autor:

Formate disponibile

IxChariot Scripts Development

and Editing Guide

Ixia Worldwide Headquarters

Part 2nd floor,

Clarion House, Norreys Drive Support: support-emea@ixi-

EMEA Maidenhead, UK SL6 4FL acom.com

+44 (1628) 408750 +40 21 301 5699

FAX +44 (1628) 639916

Nishi-Shinjuku Mitsui Bldg

Tower 1, 7th Floor, UMIYA

Cessna Business Park

Survey No. 10/1A, 10/2, 11 &

Bangalore East Taluk

Chapter 1: About This Guide 1

Procedure for Creating a New Script 19

Supported RTP Payload Types 40

Rules for Writing Scripts for Application Groups 101

Chapter 1: About This Guide

Chapter 2: Application Scripts Overview

How IxChariot Uses the Scripts

Synchronized Pair Testing

Chapter 3: Application Script Structure

Table 3-1. Required Commands in a Nonstreaming Script

END_LOOP Ends the inner loop.

SLEEP Specifies the initial delay, in milliseconds.

Maximum Number of Commands

Chapter 4: Editing and Creating Scripts

Accessing the Script Editor

Editing the Script Used by a Single Pair

To edit a script used by a single pair, follow these steps:

Editing the Script Used by Multiple Pairs

Saving Script Files

Choosing one of the following:

Editing Parameters and Variables

Editing a Parameter of a Script Command

3. Make any desired changes.

Editing a Script Variable

3. Make any desired changes.

Adding, Moving, and Deleting Commands

Moving and Deleting Commands

Command Insertion Example

l The insertion point is a block of commands: rows 6, 7, and 8 in this example.

Adding a New Script

Procedure for Creating a New Script

For More Information

Short Versus Long Connections

Disabling the Nagle Algorithm

Selecting RFC768 UDP

Disabling the UDP Checksum

Setting the Transmit MSS Option

[E1] --- SYN [TCP MSS=1000]---> [E2]

[E1] --- TCP [payload 800 bytes] ---> [E2]

[E1 MSS: 500]--- TCP[payload 500 bytes]--->[E2 MSS: 400]

Script Editor User Interface Reference

The File Menu

The Edit Menu

The Insert Menu

MSS option Sets the transmit MSS for E1.

Script Editor Toolbar

Validate Script Checks the script for errors and inconsistencies.

Swap Sides Exchanges the positions of Endpoint 1 and Endpoint 2

Insert Connect Inserts a CONNECT command at the beginning of the script.

Insert Confirm from

Insert Loop Inserts a LOOP command at the desired location.