 |
|
|
|
|
|
|
|
 |
|
||||||
 |
 |
 |
 |
 |
 |
 |
|
Medusa Labs Test Tools FAQ
Installation
I am getting the error message, “Unable to determine
the product installation directory”, after I install and try to
run the Tools.
The Tools look for an environment variable that points to the installation
directory. This variable is created during installation. Try opening a
new command prompt or terminal window and see if the problem persists.
It is sometimes necessary to reboot the system to completely register
the system environment variable. Make sure that the variable is present
in the system environment variable list. Ex. MEDUSA_MLTT_INSTALL_DIR=C:\Program
Files\Finisar\Medusa Labs\Test Tools\
I get a pop-up error dialog stating that a DLL can’t
be located when I try to run the Windows GUI.
The GUI requires the Microsoft .NET GUI. You will need to run the setup
for the .NET framework, which is provided on the installation CD (dotnetfx.exe.)
General
What is the difference between the Pain and Maim tools?
The primary difference between the Tools is their I/O dispatch method.
Pain uses a threaded engine, where each thread sends and waits on a single
I/O at a time (synchronous I/O.) Maim uses a single thread to send multiple
I/Os at a time and processes the I/Os as they individually complete. Each
Tool has its own strengths.
Pain
The threaded model makes Pain a good all-round system tester (multi-threading
works processors and memory busses better with all the context switching.)
Pain is very fast with low thread counts and small file sizes. It can
slow down as the numbers increase. I/O to disks becomes somewhat random,
as each thread has its own file or disk extent of the file size.
Pain has a memory only I/O mode.
Synchronous I/O is usually better suited for file system tests, especially
with network shares.
Maim
Asynchronous model can offer more precision I/O traffic control with lower
overhead.
Can produce bursty, fluctuating queue depth or static queue depth (great
for maintaining max stress or pushing queue full.)
May produce better performance out of target by working in a smaller disk
area (single file area in single worker thread.)
I just typed “pain” or “maim” at my
command line at hit enter. This appears to have started a test. Where
is this running to?
When you run one of the Tools without any arguments, they will start an
I/O test with the default switch configurations to a data file in the
current working directory. To display the online help, enter “pain
–h” or “maim –h”.
How many concurrent threads or asynchronous I/Os do the tools
support?
The tools support a maximum of 512 threads or I/Os per instance.
What is the maximum file size that the tools can access?
In general the tools are capable of accessing a maximum file size of 2GB,
per thread. The asynchronous tool, Maim has an I/O mode (-m18) that is
capable of addressing virtually limitless storage extents for full target
coverage.
Is there a way to control the LBA range which I run my traffic?
Not exactly. Currently, the only location input the tools accept is offset
in MB. This is the –x switch. Ex. –x10 for 10MB. The tools
automatically start at a base offset of 1MB (LBA 0x800), to avoid overwriting
critical parts of the drive (signature.) You can override the base offset
with the –O switch. File size can be used to set the ending LBA
(just divide file size by sector size add the starting offset to figure
out where the tools will stop.) Note that file size is per thread. So,
to be precise with starting and stopping points, you have to use a single
Pain thread or use Maim (which uses a single worker thread.)
Is there a lookup table of errors generated by the test suite?
Please see Appendix E of the User’s Guide for a listing of error
codes returned by the tools. These are our internal error codes. The Tools
will also report any OS error codes and messages (when available) to the
console and log files.
Why am I getting an xterm or dtterm error when I try to start
a test with Catapult from a telnet or ssh session into my UNIX system?
Currently, Catapult requires a GUI desktop session on UNIX platforms (CDE
on Solaris, Gnome/KDE on Linux.)
When I start a test with Catapult (ex. catapult –p pain), it runs
to all of my drives. Is there a way to select only the drives I want?
Yes, Catapult has two switches that can be used to explicitly set what
drives to run to. The include switch (-i) will cause a test to run to
only the drives indicated. The exclude switch (-x) will cause a test to
run to all drives except the drives indicated. Drives may be specified
individually or as a range. Ex. catapult –p –i2,4,7-10 pain
Why do I get a message from Catapult about drives being excluded
due to no drive signature?
Catapult uses drive signatures to track which drives contain the operating
system and any active partitions. This is a protection mechanism to prevent
accidental destruction of critical OS areas. It is best practice to make
sure all drives have a signature. Catapult does have a switch to override
the signature check (-o), but we recommend that you allow Catapult to
perform the default check.
Why won’t the Tools exit when I hit CTRL-C or try to
kill the process?
In test environments, there is always the chance that one or more I/Os
sent by the Tools may be held up in a lower level. In such a case, the
Tools may not be able to respond. This is more likely to be seen in logical
or physical drive tests. For example, a target may reset while an I/O
is pending, leaving a device driver to initiate a recovery routine that
can easily take many seconds or minutes. Particularly when using the Maim
Tool, an I/O may be held up a kernel level with the application locked
up waiting for release.
What does it mean when I get I/O halt or I/O timeout error
messages?
The Tools automatically monitor I/O traffic for any interruptions that
would warrant further investigation and display an error message. There
are two conditions that are checked in each performance sample. First,
the Tools will report if there are no completions at all in a performance
sample (sample interval is 5 seconds by default.) This is considered to
be an I/O halt (all traffic has stopped for one or more sample intervals.)
Second, the Tools will report if one or more I/Os have not completed in
a performance sample, but other completions are occurring. This is considered
to be an I/O timeout or “stuck” I/O scenario. The time interval
for detecting these conditions can be increased or disabled with the –M
switch on the Pain or Maim command line.
Licensing
I want to run a scripted test for an extended period, but
my license checkout only has a short time remaining. Is there any way
I can extend the checkout time?
Yes, you can perform a check-in of your current license with the –Z
switch (ex. Pain –Z.) Then, perform a new checkout of the desired
duration (ex. Pain –Z7 to checkout for 7 days.)
I’m getting an Error 18 licensing error on the console when
I try to run the tools. What does this mean?
This error essentially means that the license state stored on the system
is invalid. This may be the result of a natural expiration because the
checkout time has been exceeded. A hardware change, such as the removal
of a NIC can cause this. It may also indicate that the license state is
damaged due to tampering with the system clock or license lock files.
Ensure that the system clock is correct. The tools will always try to
contact a license server when a local license check fails. The license
server should issue a license if one is available. Alternatively a remote
license may be installed if a license server cannot be reached.
The tools cannot checkout a license from my license server.
There are a number of possible causes for a failure to get a license from
the server. Make sure that system date and time is correct. A restart
of the license server may correct the problem. If you still cannot check
out a license, check the following.
Is the server accessible over the network? From the client
system, can you ping the server by name or IP address?
YES: Check the server name listed in the MedusaTools.cfg file in the config
directory. We recommend using IP address to avoid name resolution issues.
NO: There is a communication issue between the client and server that
is independent of the Test Tools.
Is the license service responding? From the client system,
run “lsmon server_ipaddress” (Ex. lsmon 192.168.1.2). Does
the license server respond with a status output?
YES: Check the status output. Are there available license tokens? Has
the license expired?
NO: The service may not be running. Make sure that the SentinelLM service
is running on the license server. Make sure that nothing is blocking port
5093.
From the client system, run Wlmadmin. Enter the license server
ip address as a defined server. Does the Feature Name (MLTestTools) appear
under the license server?
YES: Make sure that there are free tokens (users.) Make sure that the
license has not expired.
NO: Try re-adding the license file (right-click the server and add license
to server and its file.) If the license can’t be added, the USB
dongle may not be attached or the driver is not running. There may also
be a problem with the license file.
Does the license file exist on the server? Go to the Windows
Service manager and check the properties of the SentinelLM service to
find the directory that it is running from. Go to this directory and check
for this file.
YES: Check the file for expiration (should have the expiration in clean
text.) Run “lsdecode –s lservrc” and check license details
for accuracy.
NO: Try copying the license file to this directory and restarting SentinelLM.
If the Feature Name is still not visible from Wlmadmin, the USB dongle
may not be attached or the driver may not be running.
Is the Server’s USB dongle attached and working? Make
sure the USB dongle is attached to the system. Check for its existence
in the Windows Device Manager under USB devices (Rainbow SuperPro.)
YES: Run Wechoid.exe on the license server and uncheck all boxes except
the computer ID. Note the locking data at the bottom of the screen. At
a command prompt, change to the directory where the license server is
installed and run “lsdecode –s lservrc”. The locking
values should match what is displayed in Wechoid.exe..
NO: Try reinstalling the USB driver
The Tools are taking a very long to perform a license check
on my Linux system.
Make sure that the host name is correctly set. If your system is reporting
“localhost” as the host name, there is a problem with the
host name configuration. Refer to the documentation for your Linux distribution
for information on setting the host name.
I did a remote checkout with GetKey to get the Tools running
on a system off of my network. Is there a way to check the license back
in?
No, remote checkouts must expire naturally. Make sure you only perform
a remote checkout for the number of days required to avoid tying up a
license unnecessarily.
Performance
The performance numbers reported by the tools are too high
to be real. Is there a problem with the calculations performed by the
tools?
Higher than expected performance is typically the result of caching by
the host operating system. This can happen when running to file systems
on any operating system or to physical block devices on UNIX platforms.
This behavior may be seen in spite of I/O operation flags being set to
a non-buffered mode (default for the test tools.) Using the –c (commit)
switch on the tools may help alleviate some performance anomalies. Whenever
possible, Medusa Labs recommends running the test tools to physical (raw)
devices for optimal performance and accurate reporting. On Linux systems,
the “raw” utility should be used (run “man raw”
for more information.) On Solaris systems, the /dev/rdsk device paths
should be used.
Why do I sometimes see the performance samples on screen vary
from the set interval?
The performance samples are created with a dedicated worker thread. Due
to extreme system load, there may instances where the thread is interrupted
during the performance sample calculations. In extreme cases, it may take
considerable time for the thread to be serviced again and execute the
console and log print functions. This will result in a sample interval
that exceeds the set interval and produces skewed sample output. Thread
starvation may be alleviated by decreasing the number of worker threads
and/or target devices.
Data Patterns
Can I create custom data patterns?
The tools can read any existing pattern file you might have.
Ex. pain –l0 -@c:\pattern.dat.
There are a number of switches that allow customizing of our stock patterns
(-L, -e, -E, -I, -F.) The –l99 pattern is extremely useful in this
capacity.
Data Integrity
Will "stale" data corruption scenarios on a target
device be detected by the tools?
The test tools utilize a number of methods to maintain a focused, yet
varying write data stream. Most data patterns are “reversible”,
i.e. they run in one direction on one write pass and the opposite direction
on the next pass, continuously alternating. A few data patterns change
on the fly with each write pass. By default, all patterns are overlaid
with a continuously changing unique I/O signature in every sector. These
measures are designed to catch any instances of data corruption as a result
of stale data being returned on a read-back operation.
I started running some tests on physical drives on a Windows
system. The Tools are reporting data corruptions that I don’t believe
are real.
Before you run a physical drive test, make sure that any old partitions
are deleted and reboot your system. We have seen cases where a test is
started on a physical drive that used to host a file system and the NTFS
file system manager is not aware that the partition has been removed.
Latent file table updates may be sent down over data written by the Tools.
This is usually seen as data corruptions 4K in size.
Test Configurations
Why am I seeing writes when I specified a read only test?
When you use the –r switch with data comparisons enabled (this is
the default behavior), there will be one write pass through the entire
file size specified, followed by continuous read only traffic. The purpose
of this write pass is to lay down the indicated data pattern (or a default
pattern, if one is not specified.) In this manner, the data pattern will
be continuously verified during the read only testing. If data integrity
is not a concern, as in pure performance testing, the –r and –n
switches can be used together. This will turn off data compares and the
reads will return whatever information is currently on the target.
Since 1997, Gillaspy Associates has built
a solid reputation for developing strong relationships with our customers
by providing quality solutions and ongoing support.
Downloads
Medusa Labs Test Tools Suite Datasheet
Test Services
Medusa Labs Test Services
Initial Evaluation
Functional
Product
Enterprise
Performance &
Benchmarks
Lab Overview
Test Tools
Medusa Test Tools Suite
FAQ
Training
Overview
Certification
Courses
Course Calendar
Register
Training Locations
Medusa Labs
