Methods

The goal of the throughput experiment was to measure the amount of sequence data processed per unit time as the number of processors increases. Since Experiment 1 established a linear relationship between BLAST performance and sequence length except for very short sequences, we chose to use only one length for the throughput experiments -- 500 bases. We chose the Visna virus sequence as our test sequence for this experiment because its search time and number of word hits were representative of many other sequences in the content test. We allocated one BLAST process per processor, and measured the system's performance as more processes and processors were added. We did the same test on the three SMP machines: Cray CS6400, Sun SC2000, and the SGI Challenge.

The goal of the response time experiment was to measure the amount of time spent searching as the number of processors increases. We also used the Visna sequence for our response time experiment. To test for possible non-linear scalability of the BLAST algorithm with an increasing number of processors, we tested Visna at all four lengths (250, 500, 2500, 9202 bases). For a given sequence length, we ran each BLAST algorithm with from one to a maximum of 24 processors on the three multiprocessors.

For the response time test, we encountered a bug in the Solaris operating system on the Sun SC2000. Individual threads of a single run would jump from processor to processor and spend much of the time in context switches instead of doing useful computation. Sun fixed the problem with the scheduling algorithm in the operating system, and the test was repeated.

On the SGI Challenge, we occasionally encountered anomalies in the measurements, because individual outputs of each algorithm run were not immediately being flushed to disk and were instead being kept in the disk cache. Going to single user mode did not eliminate the anomalies. However, by calling ``sync'' explicitly to flush the disk cache between runs, we obtained consistent performance measurements.