Figure 1: Example topology

A system view

Performance will always be limited by one or more bottlenecks in the system, of which the tape drive is just one part. The goal is to make the tape drive the bottleneck . That way the system will achieve the performance figures as advertised on the drive's spec sheet.

This puts the emphasis on the rest of the system. The flow of data throughout the system must be fast enough to provide the tape drive with data at its desired rates. High-speed tape drives such as the HP Ultrium 460, 920, 960, and 1840 are so fast this can be a difficult goal to achieve. If backup performance is not matching the data sheet of the tape drive, then there is a bottleneck somewhere else in the system.

This guide is intended to help find the bottleneck and suggests ways to remove it so the backups do meet performance expectations.

How fast should it go?

The answer to this is determined by multiplying the native data rate of the tape drive by the compression ratio of the data being backed up. For example, 2:1 compressible data on an HP Ultrium 460 (30 MB/sec native) should achieve a data rate of 60 MB/sec.

Note that the internal pipeline of the tape drive might limit the ultimate data rate. In the case of the HP Ultrium 460, this is around 90 MB/sec. This is unlikely to be a limiter except in the fastest of systems.

Drive Type	2:1 Speed MB/s
DDS1	0.166667
DDS2	0.5
DDS3	3
DDS4	6
DAT 72	6
DAT 160	13
VS80	6
SDLT 220	22
Ultrium 230	30
SDLT 320	32
Ultrium 232	32
Ultrium 448	48
Ultrium 460	60
SDLT600	72
Ultrium 920	120
Ultrium 960	160
Ultrium 1840	240

Compression ratio can vary a great deal. Click here for more information on data compression and the likely compression ratios for common data types. For simplicity, data is assumed to compress at 2:1, which can be used as a working default. A better alternative is to use the actual compression ratio of data which can be found by using Library and Tape Tools (LTT) to calculate it directly from the compression logs of the tape drive. Click here for more information on Library and Tape Tools.

With the expected data rate in mind, the next step is to measure the other parts of the system to ensure they can transfer data at least as fast as that.

Tape drive performance

This is a good place to start, as the tape drive is often incorrectly considered to be the problem. This can be established with (or otherwise) certainty by checking how fast the server can access the tape drive independent of the disk subsystem and application using the tool HPTapePerf/hptapeperf (or the Device performance function of L&TT ). It works by transferring pre-loaded data directly from the memory of the server to the tape drive. It can also use different compression ratios.

If the expected data rates cannot be achieved, then any of the following factors may be apparent:

• Cabling from server to tape drive
  • Should be good quality Ultra 160/320 SCSI cabling.
  • Should be within SCSI specs - watch for length.
  • Should be terminated properly.
  • Check for any bent pins or badly seated connectors.
• Other peripherals on the bus - high-speed tape drives must have exclusive access to the HBA/bus to achieve their potential bandwidth. Also, SCSI devices negotiate to match the lowest speed device on the bus - a legacy device can bring everything else on the bus to its knees. Therefore the faster tape drives should be connected to a dedicated bus.
• HBA/OS/driver compatibility - check that the configuration is supported at Go-connect and that the drivers are up-to-date.
  Click here to go to Go-connect.
  Click here to download drivers.
• Damaged or worn media can cause excessive use of tape or physical retries; hence, a drop in performance is probable. Either L&TT can be used to check for poor media performance or try a new tape.
• Dirty heads - the "clean light" should be on if this is the case. HP tape drives have self-cleaning mechanisms to virtually eliminate dirty heads but a cleaning cartridge can still be used to make sure.

Disk and file system performance

There is a significant difference between the raw data rate of a disk and the rate at which files can be read from a file system. This is because traversing a file system requires multiple, random disk accesses; whereas, a continuous read is limited only by the optimized data rates of the disk.

The difference between these two modes becomes more significant as file size reduces. For file systems where the files are typically smaller than 64 KB, sequential (or disk image) backups should be considered to achieve the data rates supported by high speed tape drives.

To measure the data rate from the disk subsystem, use PAT, HPReadData or the System Performance Backup Pre-Test of L&TT and select the method used by the backup - file-by-file or sequential (note that PAT is the only tool that measures sequential performance). These tools give the actual read transfer rate that the disk system can provide which can be compared with the expected data rate.

If the disk subsystem does not transfer data fast enough, then it is a bottleneck. This could be down to any of the following factors:

• File size - less than 64 KB can reduce the average data rate significantly.
  • User data is often made up of files less than 64 KB.
  • Also, deep file structures can increase the number of directory accesses.
• The number of disk drives in a RAID subsystem - recommend at least one drive for each 4 MB/S of native tape data rate to support file-by-file backup. (For example, eight or more for the Ultrium 460, which has a native rate of 30 MB/S.)

  NOTE:

  Use the compressed data rate if that rate is the goal.

  Drive Type	Number of 4MB/s Disks Drives in RAID 5 Needed	Number of 6MB/s Disks in RAID 5 Needed
  DDS1	1	1
  DDS2	1	1
  DDS3	1	1
  DDS4	2	1
  DAT 72	2	1
  DAT 160	4	3
  VS80	2	1
  SDLT 220	6	4
  Ultrium 230	8	5
  SDLT 320	8	6
  Ultrium 232	8	6
  Ultrium 448	12	8
  Ultrium 460	15	10
  SDLT600	18	12
  Ultrium 920	30	20
  Ultrium 960	40	27
  Ultrium 1840	60	40

• RAID configuration - recommend RAID 5 with read cache enabled (best combination of data integrity and performance).
• Access to the disk system is slow.
  • Internal disks - Need to be using a PCI-X backplane.
  • Direct attach - Need at least Ultra 160/320 SCSI or FC (2 GB).
  • Network - Need Gigabit Ethernet with large transfer sizes.
  • SAN - Check the bandwidth of the fabric - allowing for other traffic.
    • Watch out for fibre to SCSI bridges. They can be a bottleneck.
• File system fragmentation - will cause additional seeks. Defragment before backing up.
• Software compression - do not use - it is not as fast as the compression hardware in the tape drive. It also requires significantly more processing power.
• Are any other applications accessing the disk subsystem?
  • Avoid any concurrent access - even to a different LUN (on the same subsystem).
  • Watch out for virus scans, often scheduled at similar times to backups.

As changes are made to the disk subsystem, re-run PAT to measure its performance.

Click here to see more information on how file system and disk configuration impact performance.

Backup application configuration

At this point it has been shown that neither the disk subsystem or tape drive are the performance limiters in the system. The next, most likely contender is the backup application itself.

These are HP's recommendations for achieving high performance with backup applications:

• For general backup, use an HP recommended backup application. Native apps (for example, tar, cpio on UNIX) are not high performance. Click here for recommended backup application software.
• For database applications (for example, SQL 7.0, Exchange 2000), use the backup functionality provided by those applications as they are tuned to make best use of their data structures.
• Use large (SCSI) transfer sizes (greater than 64 K). The bigger the better.
• Increase the system memory allocated to backup if possible.
• Data compression - HP's tape drives do this in hardware at very high speed whereas it is much slower in software on the server. Also, compressing data twice tends to give non-optimal compression ratios.
  • Make sure any software data compression is turned off.
• Use multi-threading (concurrency) if possible. This allows multiple backups to be interleaved to the tape, thus reducing the effect of disk seeks for each one.
  • Note this can have an impact on restore time as a particular file set is interleaved amongst other data.
• If the system consists of small files (less than 64 KB) consider image/sequential backups. See below.

Server capacity

The server is central to the backup process as it runs the backup software and the data is passed into and out of the server's main memory as it is read from disk subsystem and written to tape.

To see if the server is a possible bottleneck use one of the readily available system monitoring tools, such as PerfMon, while performing a backup. Ensure there are still resources free. Watch for the following:

• CPU bandwidth

  Drive Type	Win 32 Processor Speed/ drive (MHz)	Win 64 Processor Speed/ drive (MHz)	PA RISC Processor Speed/ drive (MHz)	HP-UX Itanium Processor Speed/ drive (MHz)
  DDS1	50	33	25	25
  DDS2	50	50	33	25
  DDS3	100	66	50	50
  DDS4	125	100	75	66
  DAT 72	125	100	75	66
  DAT 160	225	166	133	125
  VS80	125	100	75	66
  SDLT 220	333	250	225	166
  Ultrium 230	450	325	300	225
  SDLT 320	475	350	300	250
  Ultrium 232	475	350	300	233
  Ultrium 448	700	500	433	350
  Ultrium 460	850	633	550	433
  SDLT600	1 Gb	733	650	525
  Ultrium 920	1.6 Gb	1.2 Gb	1 Gb	850
  Ultrium 960	2.2 Gb	1.6 Gb	1.4 Gb	1.1 Gb
  Ultrium 1840	3.3 Gb	2.4 Gb	2 Gb	1.7 Gb

• Memory capacity

  Drive Type	RAM needed (MB/drive)
  DDS1	32
  DDS2	32
  DDS3	48
  DDS4	48
  DAT 72	48
  DAT 160	80
  VS80	48
  SDLT 220	96
  Ultrium 230	128
  SDLT 320	128
  Ultrium 232	128
  Ultrium 448	192
  Ultrium 460	224
  SDLT600	256
  Ultrium 920	384
  Ultrium 960	512
  Ultrium 1840	768

• IO bandwidth

HP recommends:

• Multi-processor or single 1+GHz processor with at least 512 MB of system memory.
• 64 bit/66 MHz PCI and HBAs. PCI-X (133 MHz) is even better.
• Use separate PCI busses for the disk and tape HBAs if possible. Total PCI bandwidth needs to be more than double the backup rate.
• Ensuring synchronous negotiation is turned on in the SCSI HBA.
• Not running any other applications during the backup. Watch for the following:
  • Virus scans
  • CPU intensive screen savers

Also, check for the following:

• Other HBAs sharing the bandwidth of the PCI bus. Keep the loading to a minimum.
• OS/HBA/Backup app compatibility:
  • Click here to verify that the configuration is supported.
• Up-to-date drivers and firmware:
  • Try latest OS/HBA drivers. Click here to download drivers.
  • Try latest HBA BIOS.
  • Try latest drive firmware (use L&TT). Click here for more information on Library and Tape Tools.
  • Try latest backup app patches.

Server set-up

One thing to watch for is the allocation of IRQs for the HBAs for both the tape drive and the disk subsystem. If either of them share an IRQ (interrupt) with something else, then there will be additional overhead in the management of interrupts. This can reduce performance significantly.

The best way to find out how the IRQs are allocated is to do so in the BIOS. This is also the best place to change them if it is desired to do it manually. Do not use the Windows device manager as this does not always give accurate IRQ allocation.

There are a number of possible workarounds:

• Re-allocate the IRQs in the BIOS.
  • Force slow hardware to share IRQs (for example, serial ports).
  • Allow fast hardware to have its own IRQ.
• Re-arrange the hardware to use different slots. With plug and play this can be a bit of a lottery. Use the manual method (BIOS allocation) if possible.
• Remove the hardware of the shared interrupt (assuming that the hardware is not required).
• Disable the hardware of the shared interrupt (assuming that the hardware is not required).
  • Can be done in the BIOS or device manager.
  • Has the advantage of not need to take the server apart.
  • Unused serial ports are a good candidate.

One other thing to watch for on Windows operating systems, is the Removable Storage Manage r (RSM). This system service polls the drive regularly, which interrupts the flow of data and therefore reduces the overall throughput. This system service polls the drive regularly, which interrupts the flow of data and therefore reduces the overall throughput. The workaround is to disable the service, but beware - re-connecting any storage devices will automatically turn RSM back on again, including devices via USB.

Make sure to regularly check that RSM is disabled.

File by file versus image/sequential backups

One of the biggest performance gains can be made by switching from file by file backups to image or sequential backups. This can be demonstrated by comparing the data transfer results from the two different modes using PAT.

It is the backup application that defines what type of backup is to be performed. Consult the User's Guide of the respective application for details on how to select the mode. Most applications, including HP's Data Protector refer it as "Image" mode, Veritas NetBackup refers to it as "FlashBackup."

There are significant disadvantages to performing backups in image mode so carefully consider them before making the switch.

• Image mode is a complete backup of a single partition or LUN. A subset, such as a file or set of files, cannot be backed up in this way.
• When restoring, the complete partition (or LUN) must be restored as a single operation unless the application is able to extract the required data itself. This can add considerable time to a selective restore.
• Unless doing a full restore, a spare partition may be needed to restore to, so as not to overwrite data in the active partition.

The trade-off is effectively between backup performance and ease of restoring subsets of the partition or LUN.

Disk to disk backups

A good way of meeting the performance needs of the tape drive and also allowing file-by-file backups (for ease of selective file restore) is to use the following:

• File based, disk to disk (LUN to LUN) backup followed by
• Image backup of the backup disk to tape

This is also known as staging. It has the following advantages and disadvantages:

• Low speed disk to disk backup will not affect the tape drive.
• The image backup to tape can be done "offline" and therefore the user data on the main LUN can be live and operational at the same time.
• Individual file restore may be done from the backup LUN as long as it is preserved.
• Total backup time is longer as it is now a two-stage process (though user disruption is less).
• Maintain space for the copy of each LUN that is to be to preserved (for selective file restore). This could double the disk storage requirements.

Backup versus restore

Most of the use of a tape drive is for the backup of data. Restore tends to be reserved for when something has gone wrong on the disk (corruption, loss) and there is a need to get some or all of the data back.

The tape drive writes and reads at the same speed but, importantly, the disk system does not. When writing data back to disk, the file structures need to be created and this takes extra head movements. Also, advantage cannot be taken of the read cache.

The performance of the disk subsystem can be measured using HPCreateData/hpcreatedata or the System performance Restore Pre-Test function of L&TT . This creates a directory structure based on file size, directory depth, directory width and compression ratio and measures the data rates it achieves.

If there are issues with restore performance, then check the backup performance first. If that is OK, then it is almost certainly the disk subsystem that is the bottleneck and the section on Disk and File system performance needs to be re-visited. There are three main options:

• Upgrade the disk hardware - for example more or faster disks.
• Use image backup/restore - the file structures are copied at the same time.
• Accept that restore performance is not as fast as backup performance. If restore is only needed occasionally, this may be acceptable.

What about block size?

Many tape drives have internal overheads to manage SCSI blocks as they come through. Examples are DDS, DLT. For these, it is important to also use large (larger than 64 KB) block sizes.

The HP Ultrium tape drive manages SCSI blocks in hardware so there is no overhead per block. For these tape drives, the block size does not affect performance.

How important is performance?

The answer to this question depends on what is needed. If, after following the advice above, the transfer rate of the tape drive still cannot be reached - and this really can be a challenge with the high transfer rates supported by HP's Ultrium and SDLT tape drives - then it is not necessarily a problem unless that performance is needed. The key requirement may just be that the backup completes within the available time window.

As upgrades are done on the server, disk system, network or other parts of the whole system, better use of the performance of the tape drive will be possible. If the maximum performance is not being achieved at the moment, at least feel good about investing in a backup solution that will match the system well into the future.

The following table shows the native data transfer rates of a range of HP's currently supported tape drives. HP's Ultrium drives also have a feature called Adaptive Tape Speed (ATS), which matches the speed of the tape to the data rate of the server. It is fully variable between its lowest and highest rates and eliminates tape repositions within this range - thus reducing wear even if the server cannot keep up.

Tape drive	Lowest native data rate	Highest native data rate	Highest rate with 2:1 compression
HP DAT 24	n/a	1 MB/Sec - 60 MB/min	120 MB/min
HP DAT 40	n/a	3 MB/Sec - 180 MB/min	360 MB/min
HP DAT 72	n/a	3 MB/Sec - 180 MB/min	360 MB/min
HP DLT VS80	n/a	3 MB/Sec - 180 MB/min	See note below
HP DLT 80	n/a	6 MB/Sec - 360 MB/min	See note below
HP DLT VS160	n/a	8 MB/Sec - 480 MB/min	See note below
HP SDLT 220	n/a	11 MB/Sec - 660 MB/min	1320 MB/min
HP SDLT 320	n/a	16 MB/Sec - 960 MB/min	1920 MB/min
HP SDLT 600	n/a	36 MB/Sec - 1920 MB/min (1.92 GB/min)	3840 MB/min
HP AIT 70	n/a	4 MB/Sec - 240 MB/min	480 MB/min
HP AIT 100	n/a	6 MB/Sec - 360 MB/min	720 MB/min
HP AIT 200	n/a	12 MB/Sec - 720 MB/min	1440 MB/min
HP Ultrium 215	6 MB/Sec	7.5 MB/Sec - 450 MB/min	900 MB/min
HP Ultrium 230	6 MB/Sec	15 MB/Sec - 900 MB/min	1800 MB/min
HP Ultrium 232	10 MB/Sec	16 MB/Sec - 960 MB/min	1920 MB/min
HP Ultrium 448	10 MB/Sec	24 MB/Sec – 1440 MB/min (1.4 GB/min)	2880 MB/min
HP Ultrium 460	10 MB/Sec	30 MB/Sec - 1800 MB/min (1.8 GB/Min)	3600 MB/min
HP Ultrium 920	26 MB/Sec	60 MB/Sec - 3600 MB/min (3.6 GB/Min)	7200 MB/min
HP Ultrium 960	27 MB/Sec	80 MB/Sec – 4800 MB/min (4.8GB/min)	9600 MB/min
HP Ultrium 1840	40 MB/Sec	120 MB/Sec - 7200 MB/min (7.2GB/min)	14400 MB/min

If a data rate can be achieve above the minimum ATS speed, then the drive will stream. For example, it will be operating at minimum wear rates. As a last resort, turn data compression off. This would be more likely to stream, although it would use more tape for the same amount of data.

How important is performance - wear and tear?

The tape drive should be operating at or above its lowest streaming data rate to achieve the best life for the head, mechanism, and tape media. If the data is not sent fast enough, the internal buffer will empty and the drive will not write a continuous stream of data. At that point, the drive will start exhibiting what is called head repositioning. Head repositioning is also known as "shoe shining" and it causes excessive wear on the tape media, on the tape drive heads, and on the mechanical tape drive components.

Tape media life and tape drive read-write head life is measured in the terms of how many times the tape passes over the heads. As the tape media passes over the tape drive read-write heads, little flakes of magnetic material are worn off the tape and the heads also slowly wear down. Over time, and a sufficient number of passes over the heads, the tape media will wear down to the point of losing error rate margin. The drive heads will also slowly wear down and as the wear increases, they will incur more misreads and require more retries. This will slow down the backup and have more potential for backup or even restore failures. As these errors and re-tries increase, the drive will interpret that it needs cleaning and may start asking for a cleaning tape when it does not really need cleaning. In some cases, the cleaning media can be relatively abrasive and compound the wear on the heads, making the situation even worse.

For example, DLT read-write heads are rated at a life of 1,000,000 passes of the tape media passing over the read-write heads. The tape media itself also has a rated life of 1,000,000 passes, but the effective life is only 500,000 passes since the tape may become unreliable after it is worn down past the half way point. Normally, a DAT drive could have a long life of four or five years and a DLT drive could last for six or more years if maintained properly. But many customers do not get as much life out of their tapes and tape drives because of excessive wear. This wear usually exhibits as a drive that is asking to be cleaned frequently or even failing backups occasionally. It is very important to keep the drive streaming.

Tape drives have buffers in the data path that are large enough to prevent head repositioning or "shoe shining" from explicitly slowing the backup down further; however, the increased error rate from worn heads/media causes more tape to be used and additional retries to be performed. This will slow the backup down and over time it will get worse. It is possible for a two-hour backup to take ten or twelve hours to complete for a severe case.

Performance troubleshooting flow (Quick reference)

This is a brief summary of the set of steps to follow when troubleshooting backup performance issues. It is intended to be used as a quick reference once the main guide has been read.

• Calculate the expected data transfer rate for the backup (Ave. Compression Ratio * native tape rate).
• Verify that the tape can go that fast - use HPTapePerf /L&TT .
• Verify that the disk subsystem can provide data that fast - use HPTapePerf /L&TT .
• Verify that the backup application is configured correctly .
• Verify that the server has sufficient capacity - use Perfmon; and, verify that it is setup correctly - check the IRQs.
• Verify that the disk subsystem can accept restored data at the expected data rates - use HPCreateData /L&TT ..

Introduction

The tools described below will help to debug problems down to component level:

• Backup performance analysis tools
  • Tape drive analysis tools
    • HPTapePerf/hptapeperf - tape drive data transfer measurements (HP)
    • L&TT (Device performance) (HP)
    • DPMETERM - tape drive data transfer measurements (Novell)
  • Disk subsystem analysis tools
    • PAT - File system and raw disk read performance measurements (HP)
    • HPReadData/hpreaddata - Like PAT but with multi-pathing capability
    • L&TT (System performance – Backup Pre-test) (HP)
    • TSATEST - Netware SMS file system performance measurements (Novell)
    • DD - Raw disk performance measurement (image mode)
    • LMDD - Linux version of DD
• Restore performance analysis tools
  • Disk subsystem analysis tools
    • HPCreateData/hpcreatedata - File system generator for restore performance measurements (HP)
    • L&TT (System performance – Restore Pre-test) (HP)
• General system performance analysis tools
  • IOMETER TTCP - IP - System performance analysis (Intel)
  • (Ethernet) performance analysis (Cisco)
  • Task Manager - Windows

PAT

Description	Written by HP allows user selected files to be read in order to simulate the way a backup application reads the files through the filesystem. Can also be used to simulate reading data from "shared" drives over a network and also to model image mode backups. Gives results in MB/S.
When to use	Use to evaluate the most likely backup performance from the disk subsystem for file by file, across the network or image.
How to use	Click the link at the bottom of the page to download the PAT software onto your local machine.

HPReadData/hpreaddata

Description	Similar to PAT but with wider platform support. Allows up to eight paths to be specified for the simulation of multiple stream access to data. Available for the following:
When to use	Use this to assess the disk subsystem / filesystem read performance on actual data to be backed up, a single stream will simulate the performance of most backup applications. Using multiple streams will simulate the overall throughput if the backup application supports multiple streams.
How to use	Click the link at the bottom of the page to download the HPReadData software onto your local machine.

TSATest

Description	Written by Novell. Performs multiple disk read to determine the average throughput which can be expected through the NetWare SMS Filesystem
When to use	Used to verify disk performance. Disk subsystem performance through the filesystem is a likely cause of poor backup performance on NetWare unless backup applications utilize the multiple thread capabilities of the TSA drivers.
How to use	Click here to go to the Novell Web site.

DD

Description

Data source to data source, and is standard on all Unix-en. It also is not specific to tape/disk, it moves anything between here and there; where "here" and "there" can be any UNIX file or device.

LMDD

Description	Lmdd is used in a similar manner to dd on UNIX platforms. It differs from the standard dd, however, in that it will report back the MB/sec transfer rate obtained between data source and destination.
When to use	Use this tool to assess the underlying maximum performance read capability of the disk subsystem by reading the disk without the filesystem overhead. This may be useful in determining how fast a "serverless" backup might run - in terms of speed of access of source data; and also in calibrating expectations of filesystem performance upon the raw disk.
How to use	Lmdd is available from the Bitmover Web site .

HPTapePerf/hptapeperf

Description	Written by HP, writes data directly from memory to tape at different compressibility levels. Can also be used to read from tape to memory.
When to use	Use to verify the absolute performance of the tape drive independent of the rest of the backup system. Allows different block sizes, transfer lengths and overall size of transfer to be configured. If the performance of the drive is as expected then any performance issue is likely to in another part of the backup system (for example, the disk subsystem). Requires a moderate knowledge of tape drive terminology.
How to use	Click the link at the bottom of the page to download the HPTapePerf software onto your local machine.

No tape devices found by HPTapePerf?

There are a number of reasons why HPTapePerf may not be able to see the device. See below:

DPMETERM

Description	Written by Novell, similar to hptapeperf writes data from memory to tape.
When to use	Use on NW5.x/6.x to independently confirm the Tape Drive performance is as expected. If performance is OK, then Filesystem or Disk Subsystem is likely to be the performance bottleneck.
How to use	Run executable and follow on screen instructions.

HPCreateData/hpcreatedata

Description	Written by HP, creates files and directory structures to measure the restore performance of the disk subsystem and/or generate controlled data for backup tests.
When to use	Use this to produce a known data source of known compressibility to evaluate tape drive or backup application performance. For example, small file backup, large file backup, data compression efficiency, etc. Also, use for measuring restore performance of the disk subsystem.
How to use	Click the link at the bottom of the page to download the HPCreateData software onto your local machine.

IOMETER

Description	An Intel product - now in the open source community. This is a sophisticated product capable of assessing a wide range of system performance parameters; interpretation of the results needs a higher degree of system understanding. Windows Platforms only.
When to use	Best used when doing in-depth assessment of Disk Array performance, where IOPs measurements are required and to monitor the "transaction" performance of disk subsystems when high queue depths are involved.
How to use	Downloadable from the sourceForge Web site .

TTCP

Description	Available on a number of FTP sites, and also a Web page provided by CISCO. Allows any IP path to be tested for performance. Provides Downlink and Uplink tests. Can be used on Windows and UNIX.
When to use	Can be useful in the following: Determining how fast the source data on remote clients can be accessed by the backup application. For assessing how Gigabit Ethernet might improve the backup performance situation . For assessing how TOES (TCP offload engines) might improve the backup performance situation.
How to use	Available from a Cisco Web page, amongst other locations:

Figure 5: Example screen shot of L&TT (Windows version)

NOTE:

After clicking the link to download the tool, verify that your current version of the operating system is supported by the tool.