1

I am testing out a new Quantum Ultrium 8 Tape and Drive. I see the listed maximum uncompressed and compressed data rate, respectively, are 360 MB/s and 900 MB/s. How can I observe/demonstrate this level of performance most simply? I was trying this:

dd if=/dev/urandom of=/dev/shm/random-data bs=64M count=16

end=$((SECONDS+60))
while [[ $SECONDS -lt $end ]]; do
    dd if=/dev/shm/random-data of=/dev/nst0 bs=1M count=1024
done

Chunk of the output:

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 7.66494 s, 140 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 8.10491 s, 132 MB/s
...

I got an average speed of 126 MB/s. When I tried to test the compressed data rate, by filling up another file in /dev/shm/ with 1GB from /dev/zero and doing the same loop, I got an average of 282 MB/s.

Is there another simple way to observe/demonstrate the expected data rates (or at least just the uncompressed speed)? What is causing the limitation I'm observing?

Levi Uzodike
  • 221
  • 2
  • 7
  • 1
    You're probably comparing apples to oranges. The data rates provided by manufacturers are typically the physical maximum supported by the medium/media with absolutely no idle time or gaps. You're measuring not at the drive but overall transfer time and rates that involve several interfaces, additional overhead, and unknown amount of buffering. FWIW the spec sheet I looked at has slightly lower transfer rates: https://cdn.allbound.com/iq-ab/2020/02/09222012/LTO-Drives-Datasheet-DS00457A.pdf BTW a huge block size doesn't help since the device cannot handle it. – sawdust Mar 03 '20 at 23:49
  • What is a good block size that the device can handle? Do you know how I can compare apples to apples? I mean is there some kind of library or command that does reporting that would test the tape speed while accounting for the overhead? – Levi Uzodike Mar 04 '20 at 00:21
  • You'll have to read the tech manual for the actual block size(s). Typical physical media limit the block size to a few K bytes for reliable error detection (and correction). Measuring apples may not be worth the effort because you have to use the device in a computer system rather than by itself. You can try different transfers, see https://stackoverflow.com/questions/6161823/dd-how-to-calculate-optimal-blocksize Using **dd** to write from **/dev/zero** or read to **/dev/null** (with reasonable blksize) should result in fastest transfer times/rates that you can expect from a block device. – sawdust Mar 04 '20 at 00:47
  • Well, I'm only interested in the tape speed, and writing from `/dev/zero` to `/dev/null` will not touch the tape, so I don't think that will help me. I guess what you're saying is that `dd` is more measuring the speed of the block device and not the tape alone? – Levi Uzodike Mar 04 '20 at 19:47
  • You're just skimming or misreading what I wrote. You would need an oscilloscope and access the logic boards to measure the transfer rate of the medium. I've done similar for disk drives in a previous job. – sawdust Mar 07 '20 at 01:30

1 Answers1

1

You can observe transfer rate with tapestat Linux command. Here is a man page.

The tapestat command is used for monitoring the activity of tape drives connected to a system.

The tapestat report provides statistics for each tape drive connected to the system. The following data are displayed: ... kB_read/s | MB_read/s The amount of data read expressed in kilobytes (by default or if option -k used) or megabytes (if option -m used) per second averaged over the interval.

For example, I would firstly create dummy data (e.g., 10GB) with /dev/urandom and store it under disk system which is faster enough than LTO's maximum transfer rate. In this specific case, disk's transfer rate shall be >360MB/sec. I would recommend SSD or tmpfs to avoid any bottleneck. Then, write the dummy data to LTO-7 media with tar, something like tar -cvf /dev/st0 dummy_data. Just after starting write process, you should invoke tapestat 1, which will show averaged transfer rate every second.

If output is less than 360MB/sec, there should be a bottleneck in your system. It can be due to SAS card speed, disk speed, internal bus speed, or even your tape drive/media is about to fail.

Kevin Nakamoto
  • 96
  • 4