The collected works of videobrat

I've run lmdd many times to evaluate disk performance (under 6.5.17), but when I put together a new origin 2100 server (6.5.22), I cannot get lmdd to run without an error:

root @ lucky7 : /mounts/shortstuff/terratwo/dpx_tiffs [39]> lmdd of=/mounts/shortstuff/terratwo/dpx_tiffs/tiffiles.00001.tif bs=12m move=500m direct=1
* * * WARNING - could not mpin memory * * *
Segmentation fault (core dumped)

root @ lucky7 : /mounts/shortstuff/terratwo/dpx_tiffs [40]> hinv
8 250 MHZ IP27 Processors
CPU: MIPS R10000 Processor Chip Revision: 3.4
FPU: MIPS R10010 Floating Point Chip Revision: 3.4
Main memory size: 7168 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 4 Mbytes
Integral SCSI controller 98: Version Fibre Channel QL2200
Disk drive: unit 0 on SCSI controller 98
Integral SCSI controller 99: Version Fibre Channel QL2200
Disk drive: unit 0 on SCSI controller 99
Integral SCSI controller 0: Version QL1040B (rev. 2), single ended
Disk drive: unit 1 on SCSI controller 0
Disk drive: unit 2 on SCSI controller 0
Disk drive: unit 3 on SCSI controller 0
CDROM: unit 6 on SCSI controller 0
Integral SCSI controller 1: Version QL1040B (rev. 2), single ended
CDROM: unit 7 on SCSI controller 1
Integral SCSI controller 2: Version QL1040B (rev. 2), differential
Integral SCSI controller 3: Version QL1040B (rev. 2), differential
Integral SCSI controller 4: Version QL1040B (rev. 2), differential
Integral SCSI controller 5: Version QL1040B (rev. 2), differential
IOC3/IOC4 serial port: tty1
IOC3/IOC4 serial port: tty2
Gigabit Ethernet: eg0, module 1, XIO slot io7, firmware version 12.4.10
Integral Fast Ethernet: ef0, version 1, module 1, slot io1, pci 2
Origin BASEIO board, module 1 slot 1: Revision 4
Origin MSCSI board, module 1 slot 9: Revision 3
IOC3/IOC4 external interrupts: 1

root @ lucky7 : /mounts/shortstuff/terratwo/dpx_tiffs [41]> top
******note - just checking memory usage here*******
IRIX64 shortstuff 6.5 IP27 load averages: 1.00 1.00 0.84 13:35:06
41 processes: 40 sleeping, 1 running
8 CPUs: 99.8% idle, 0.0% usr, 0.2% ker, 0.0% wait, 0.0% xbrk, 0.0% intr
Memory: 7168M max, 7029M avail, 5781M free, 128M swap, 128M free swap

PID PGRP USERNAME PRI SIZE RES STATE TIME WCPU% CPU% COMMAND
1719 1719 root 20 2400K 1712K run/0 0:00 0.3 0.24 top
1401 1399 grant 20 6688K 2976K sleep 0:01 0.0 0.05 sshd
257 257 root 20 2432K 1744K sleep 0:00 0.1 0.01 nsd

root @ lucky7 : /mounts/shortstuff/terratwo/dpx_tiffs [42]> uname -R
6.5 6.5.22f
root @ lucky7 : /mounts/shortstuff/terratwo/dpx_tiffs [43]>

_________________
------------------------------------------------
I saw it on TV, it must be real!
------------------------------------------------
I could also use IOzone. I had used lmdd reliably for ages - Is this perhaps a symptom of another problem? I want to fix what's broken here.

_________________
------------------------------------------------
I saw it on TV, it must be real!
------------------------------------------------
I found this in the Install notes for IRIX6.5.24/complementary_apps:

Important Notes About the Products
----------------------------------
Easy Software ESP PrintPro
Easy Software ESP PrintPro package requires a license. You can
obtain a 21-day demo license for this software by going to
the ESP web site at http://www.easysw.com/license-demo.php .

ESP PrintPro replaces several files that are part of the
IRIX print product therefore these two packages are
incompatable with one another. If you install ESP PrintPRO
and later want to remove the package, you will need to reinstall
print from the Applications CD and the current IRIX 6.5 Overlay
CD in order to restore print.
----------------------------------
------------------------------------------------
I saw it on TV, it must be real!
------------------------------------------------
Not VS160, but here's a couple of others:

Code: Select all

/* DEC THZxx SuperDLT1 drive */
{ DECDLT, TPDLT, 7, 9, "QUANTUM", "SDLT220", 0, 0,
{0}, MTCAN_BSF | MTCAN_BSR | MTCAN_APPEND | MTCAN_SPEOD |
MTCAN_CHKRDY | MTCAN_VAR | MTCAN_SETSZ | MTCAN_SILI | MTCAN_SEEK|
MTCAN_SYNC | MTCAN_CHTYPEANY | MTCAN_COMPRESS | MTCAN_SETDEN,
20, 8*60, 20*60, 5*60, 3*3600, 4096, 64*1024,
tpsc_default_dens_count, tpsc_default_hwg_dens_names,
tpsc_default_alias_dens_names,
{0}, 0, 0, 0,
0, (u_char *)0 },

/* DEC THZxx SuperDLT1 drive */
{ DECDLT, TPDLT, 7, 7, "QUANTUM", "SDLT320", 0, 0,
{0}, MTCAN_BSF | MTCAN_BSR | MTCAN_APPEND | MTCAN_SPEOD |
MTCAN_CHKRDY | MTCAN_VAR | MTCAN_SETSZ | MTCAN_SILI | MTCAN_SEEK|
MTCAN_SYNC | MTCAN_CHTYPEANY | MTCAN_COMPRESS | MTCAN_SETDEN,
20, 8*60, 20*60, 5*60, 3*3600, 4096, 64*1024,
tpsc_default_dens_count, tpsc_default_hwg_dens_names,
tpsc_default_alias_dens_names,
{0}, 0, 0, 0,
0, (u_char *)0 },

/* Quantum SDLT600 drive */
{ DECDLT, TPDLT, 0, 7, "", "SDLT600", 0, 0,
{0, 0, 0, 0 },
MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_SPEOD |
MTCAN_CHKRDY|MTCAN_VAR| MTCAN_SETSZ|MTCAN_SILI|MTCAN_SEEK|
MTCAN_SYNC|MTCAN_CHTYPEANY | MTCAN_COMPRESS | MTCAN_SETDEN,
20, 8*60, 20*60, 5*60, 3*3600, 16384, 64*1024,
tpsc_default_dens_count, tpsc_default_hwg_dens_names, tpsc_default_alias_dens_names,
{0}, 0, 0, 0,
0, (u_char *)0 },

/* SONY GY-8240 DTF2 drive */
{ SONYGY, TPGY2120, 4, 7, "SONY", "GY-8240", 0, 0, {0, 0, 0, 0},
MTCAN_BSF | MTCAN_BSR | MTCANT_RET | MTCAN_CHKRDY | MTCAN_PREV |
MTCAN_SEEK | MTCAN_APPEND | MTCAN_SILI | MTCAN_VAR | MTCAN_SETSZ |
MTCAN_CHTYPEANY | MTCAN_COMPRESS,
20, 100*60, 10*60, 9*60, 9*60, 16384, 256*1024,
tpsc_default_dens_count, tpsc_default_hwg_dens_names, tpsc_default_alias_dens_names,
{0}, 0, 0, 0,
0, (u_char *)0 },

------------------------------------------------
I saw it on TV, it must be real!
------------------------------------------------
Even though I'm under 6.5.28, the LTO3 isn't really rolled into the operating system. I hammered away at the /var/sysgen/master.d/scsi file, and rebuilt the kernel several times, but the drive hangs when I try to read it back. I've tried a couple of different setups, each time getting the same result.

This appeared to write out 380GB fine, but I wasn't able to get it to read back at all:

Code: Select all

/* Quantum LTO3 / Ultrium 3 */
{ DATTAPE, TPDAT, 8, 7, "CERTANCE", "ULTRIUM 3", 0, 0, {0},
MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_SETMK|MTCAN_PART|MTCAN_PREV|
MTCAN_SYNC|MTCAN_SPEOD|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
MTCAN_SILI|MTCAN_AUDIO|MTCAN_SEEK|MTCAN_CHTYPEANY|MTCAN_COMPRESS,
40, 5*60, 20*60, 20*60, 3*3600, 512, 512*512,
tpsc_default_dens_count, tpsc_default_hwg_dens_names,
tpsc_default_alias_dens_names,
{0}, 0, 0, 0,
0, (u_char *)0 },

Code: Select all

tape@fortune8:~/SCRIPTS[6]> hinv | grep -i tape
Tape drive: unit 6 on SCSI controller 2: DLT
Tape drive: unit 6 on SCSI controller 3: DLT
Tape drive: unit 6 on SCSI controller 6: DAT
Tape drive: unit 6 on SCSI controller 7: DLT
tape@fortune8:~/SCRIPTS[7]> mt -t /dev/rmt/tps6d6 stat
Controller: SCSI
Device: CERTANCE: ULTRIUM 3       17703106
Status: 0x20242
Drive type: DAT
Media : READY, writable, at BOT
tape@fortune8:~/SCRIPTS[8]>


unit hangs with a device error - required power cycle to wake up.

---

a little closer. This one ran better, but hung after reading back about a thousand frames (12GB):

Code: Select all

/* Quantum LTO3 / Ultrium 3 */
{DATTAPE, TPDAT, 8, 7, "CERTANCE", "ULTRIUM 3", 0, 0, {0},
MTCAN_BSF | MTCAN_BSR | MTCAN_APPEND | MTCAN_SETMK |
MTCAN_PREV | MTCAN_SYNC | MTCAN_SPEOD | MTCAN_CHKRDY |
MTCAN_VAR | MTCAN_SETSZ | MTCAN_SILI | MTCAN_SEEK |
MTCAN_COMPRESS,
40, 5*60, 10*60, 10*60, 3*3600, 512, 256*512,
tpsc_default_dens_count, tpsc_default_hwg_dens_names,
tpsc_default_alias_dens_names,
{0}, 0, 0, 0,
0, (u_char*) 0},


Code: Select all

tape@fortune8:~[1]> mt -t /dev/rmt/tps6d6 stat
Controller: SCSI
Device: CERTANCE: ULTRIUM 3       17703106
Status: 0x20262
Drive type: DAT
Media : READY, writable, at BOT
tape@fortune8:~[2]> hinv | grep -i tape
Tape drive: unit 6 on SCSI controller 2: DLT
Tape drive: unit 6 on SCSI controller 3: DLT
Tape drive: unit 6 on SCSI controller 6: DAT
Tape drive: unit 6 on SCSI controller 7: DLT
tape@fortune8:~[3]
------------------------------------------------
I saw it on TV, it must be real!
------------------------------------------------
I broke down and contacted SGI about APD for this drive. Their response follows:
--------------------------------------------------------------
Hi,
I can confirm to you that there's no support for quantum LTO 3 drives.
We only support IBM and HP. W e don't forsee quantum support in the
plans at this time.
Let me know if you want me to contact our sales rep. that takes care of
the tapes drives to ask him to send you a quote on a supported TP.

--------------------------------------------------------------
------------------------------------------------

I saw it on TV, it must be real!

------------------------------------------------
The whole point of LTO is the idea that the hardware is "open". Anyone can manufacture it. DLT is Quantum, but LTO is produced by three different manufacturers (maybe Sony will produce these too since DTF has dead ended).

from the Quantum site:
As a result of the Certance acquisition, Quantum is the world’s largest volume supplier of both tape drives and tape automation. With the breadth of Quantum’s portfolio, we will be able to provide both channel and OEM partners with a single source of backup, recovery and archive solutions not available anywhere else.[/u]
------------------------------------------------

I saw it on TV, it must be real!

------------------------------------------------
I have not purchased the IRIX LTO3 Asynchronous Personality Daemon license, as this LTO 3 drive has functioned flawlessly since I traded in the Quantum drive for the HP (and edited the SCSI file).

Code: Select all

/* HP LTO3 / Ultrium 3 */
{ DATTAPE, TPDAT, 2, 9, "HP", "Ultrium 3", 0, 0, {0},
MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_SETMK|MTCAN_PART|MTCAN_PREV|
MTCAN_SYNC|MTCAN_SPEOD|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
MTCAN_SILI|MTCAN_AUDIO|MTCAN_SEEK|MTCAN_CHTYPEANY|MTCAN_COMPRESS,
40, 5*60, 20*60, 20*60, 3*3600, 512, 512*512,
tpsc_default_dens_count, tpsc_default_hwg_dens_names,
tpsc_default_alias_dens_names,
{0}, 0, 0, 0,
0, (u_char *)0 },

Well, it's working fine, but it's SLOW. This takes about 36 hours to write a 400GB tape. This same tape extracts in about 6 hours.

I understand this would run substantially faster if I bought the APD package, but would I really get TEN TIMEs the performance if I had the $2500 APD license?
------------------------------------------------
I saw it on TV, it must be real!
------------------------------------------------
My vendor exchanged my drive for the HP, works OK, but it's slow - see my other post at http://forums.nekochan.net/viewtopic.php?t=9663
------------------------------------------------

I saw it on TV, it must be real!

------------------------------------------------