I’ve been playing with my HP 16700A Logic Analyzer and looking at boot times.
Originally the HP 16700A came with an internal SCSI drive, which was still functioning after 15 or 16 years. This SCSI drive was a 4GB Medalist Pro like a ST34520N or similar. This drive was noisy and I wanted to replace it with something solid state and hopefully gain some speed.
The SCSI2SD is a SCSI to SDcard adapter that is available from inertial computing and the original site codesrc website out of Australia. Pretty cool little device that attaches to your PC via USB for setup and configuration. The earlier versions (v4 and earlier) were fairly slow, but newer versions have added synchronous SCSI support. I originally imaged the hard drive using linux dd and wrote it back to the SD card. While I think this worked, I wanted a completely fresh install to play with, and used an externally attached SCSI CDROM drive and the boot disk to re-ignite.
Number and types of modules count
As Mark Litwack has pointed out, the number of and types of modules that are present in the chassis at the time of boot affects the times. I have a fully loaded chassis with (2) 16717As, (2) 16715As, and a 16752A. This is related to the self-tests that get executed during boot time. Some modules, like the 16752A can run their self-tests in 15-20 seconds, where the older 715A and 717A’s are slower. I’m conducting apples-for-apples testing — using the same chassis, same modules, same order — to essentially isolate the variable in the spirit of “Change one thing at a time.”
Firmware versions do, too.
For SCSI2SD versions through v5 use the latest (as of Dec 2019) 4.8.3 version firmware.
For SCSI2SD version 6, the latest version is 6.2.9. Versions 6.2.5 through 6.2.8 contain a regression that causes the SCSI2SD to report the wrong drive size.
My current boot times with SCSI2SD v3.0
From cold boot to the black/white text bios screen: 25 seconds
From Boot PRI IPL N response to beep: 35 seconds
From Boot PRI IPL N response to “Starting Logic Analysis system”: 1:05
From Boot PRI IPL N response to Agilent LA System Loading window at top of screen: 1:44
From Boot PRI IPL N response to Fully Rendered App, ready to use: 3:20
Analyzing System Performance during boot
Using SAR launched from inittab collecting data once a second, I analyzed the boot performance to see exactly where the time was being spent. Was the system spending a lot of time waiting for the disk? Was it spending a lot of time waiting for the CPU?
I’m no expert system analyzer. No server specialist. But it sure looks like me that, at least during the boot, that the system is waiting for the disk I/O to finish so it can get on with the processing. When you see areas of disk busyness and high waiting times, the CPU stops or slows down.
Testing read speeds
I’m using a simple way of testing read speeds: create a large file, use ‘dd’ to copy the file to the /dev/null device. I’d like to test write speeds too, but the problem is that /dev/zero doesn’t exist on HPUX 10.20, and neither does /dev/random or /dev/urandom. You could install a second separate drive or try to subtract read speeds out of a same-disk copy, but that’s really not ideal.
prealloc ./bigfile 250000000
time dd if=./bigfile of=/dev/null bs=8k
SCSI2SD v 3.0 with 3.6rc2 firmware: 2:17
SCSI2SD v 3.0/5.0 with 4.8.03: 1:48 (27% improvement with new firmware)
SCSI2SD v 6 with 6.2.9 firmware: 1:27 prealloc creation, 1:02 read. (over twice as fast as original device/firmware)
Maurice Smulder’s 16702B with SCSI2SD v 6 reports: 1:07
Mark’s 16702B with Acard ARS-2000SUP (installed SSD: Kingston SNV125-S2/30GB) reports: 52s
Mark’s 16702B with original IBM drive: 52s
Right now, I’m optimizing for PERFORMANCE but not for reliability, so please use your own judgment in regards your tolerance for data corruption. I’ll follow up later on how well these settings are working.
Others’ Boot Results
Mark’s unloaded 16702B takes 2:25 to get to the System screen w/ ACard adapter. With 2x 16752A, 2x 16534A, and 1x 16754A, it takes 3:42.
Mark’s unloaded 16702B takes 2:45 with the original IBM SCSI drive.
Greg Slick’s reports “an Agilent 16902B with the M-890 motherboard (the M-880 motherboard version is more common) and the
original Intel 320 series SSD running WES7 (Windows Embedded Standard 7) boots from power on to the logic analyzer application workspace
window ready in around 1:10 with a 16910A module and a 16720A module installed.”
I’m going to purchase a SCSI2SD version 6. As mentioned, the synchronous SCSI support should speed things up considerably. While the overall unit during normal operation might be CPU bound, I really think that the boot process could be optimized. Does it matter? Does waiting 2 minutes instead of 3:30 really make a difference? No, probably not, but I’m sure there are other operations which would benefit from a faster I/O subsystem. Besides, I simply love playing around with this stuff, which is really the main point of the exercise!
There have been rumors about v6 not playing nice with the 16700A-series, about it conflicting with the SCSI2SD. I have a pet theory that the new synchronous scsi support of the version 6 conflicts with older, dumber, CDROM drives — and that the CDROM drive don’t know how to downgrade to async support. Alex from Inertial Computing has said that he thinks recent firmware upgrades have solved this problem.
Thanks to everyone who has contributed test data!!