Performance Comparison of IDE and SCSI Disks
Brian White University of Virginia bsw9d@cs.virginia.edu
Abstract: It is widely believed that the IDE disks found in PCs are inexpensive but slow, whereas the SCSI disks used in servers and workstations are faster, more reliable, and more manageable. The belief that current IDE disks have performance and reliability disadvantages has been called into question by several recent reports. Thus we consider the possibility of achieving tremendous cost advantages by using IDE disks as the foundation of a storage system. In this paper, we give an extensive performance comparison of IDE and SCSI disks. We measure their performance on a variety of micro benchmarks and macro benchmarks, and we explain these results with the help of kernel instrumentation and device activity traces collected by a SCSI analyzer. We consider the impact of several factors, including sequential vs. random workloads, file system enhancements such as journaling and Soft Updates, I/O scheduling in the kernel vs. in the disk drive (as enabled by tagged queuing), and the use of RAID technology to obtain I/O parallelism. In our testbed we find that the IDE disk is faster than the SCSI disk for sequential I/O, but the SCSI disk is faster for random I/O. We also observe that the random I/O performance deficit of the IDE disk is partly overcome by kernel I/O scheduling, and is further mitigated by scheduling in the drive (as enabled by tagged queuing), and by the use of journaling and Soft Updates. Taken as a whole, our results lead us to conclude that RAID systems based on IDE drives can be both faster and significantly less expensive than SCSI RAID systems.
Wee Teck Ng, Bruce K. Hillyer Bell Laboratories, Lucent Technologies {weeteck, bruce}@research.bell-labs.com

1 Introduction

In this paper, we focus on a performance comparison of two popular hard disks types, IDE and SCSI. IDE (Integrated Device Electronics) disks, also referred to in the industry as ATA (AT attachment) or EIDE (Enhanced IDE), are the dominant storage for home computers and personal workstations, and have 85% share of the disk drive market [25]. By contrast, SCSI (Small Computer System Interconnect) disks dominate the workstation and server markets. IDE disks are much less expensive than SCSI disks: Chung et al. [24] note the potential to store a terabyte using IDE disks for less than $10,000. To capitalize on this cost advantage, companies such as Adaptec, Promise, Raidzone, Raidweb, Jetstor, and disk manufacturers Maxtor and Quantum have introduced RAID IDE controllers [1, 11, 23] and IDE RAID systems. The desire to provide more cost-effective storage solutions, on various scales, motivates a thorough comparison of the IDE and SCSI technologies. We distinguish our work in this area from previous efforts (see Section 5) by combining the following properties in this study. Our experimental testbed is specified in detail, the device specifications of our IDE and SCSI configurations are very similar, our performance experiments are comprehensive and clearly defined, the experiments represent a wide-range of configurations and workloads, and the analysis of benchmark timing measurements is supported by kernel instrumentation and by physical I/O traces obtained via a SCSI analyzer. In addition to experimental analysis, we examine four factors that partly compensate for the native performance limitations of IDE, namely disk concurrency, disk scheduling, file system design, and I/O parallelism. This paper is organized as follows. Section 2 describes differences between IDE and SCSI disks in terms of price, performance-related specifications, and interface-related specifications. Section 3 describes our experimental testbed and the benchmarks that we use for timing measurements. Section 4 presents the benchmark results and analysis. Section 5 covers related work, and in Section 6 we provide concluding remarks.

2 IDE versus SCSI

In this section, we compare IDE and SCSI technology in terms of price, performance specifications, and interface specifications, because these considerations are important in assessing the relative utility of these two technology families. To give representative device characteristics, we display specifications for six current disks and controllers in Table 1. In Table 2 we show several interface characteristics that differentiate between IDE and SCSI devices (see [25] for a more detailed comparison of these interfaces).

Model IBM 75GXP IDE Disks Seagate Barracuda ATA II Maxtor DM Plus40 IBM Ultrastar 36LZX SCSI Seagate Cheetah 36LP Disks Quantum Atlas 10K II Model Promise Ultra100 IDE Abit Hotrod100 Controller 3ware 6800 SCSI Adaptec 2940U2W Controller Adaptec 2200S Adaptec 3200S Rotational Capacity Avg. Seek Sustained Buffer Size Speed Read/Write Bandwidth 7200 RPM 30 GB 7 ms 37 MB/s 2 MB 7200 RPM 30 GB 8.9 ms 30 MB/s 2 MB 7200 RPM 30 GB 8.7 ms 49.5 MB/s 2 MB 10000 RPM 36 GB 4.9/5.9 ms 22-36 MB/s 4 MB 10000 RPM 36 GB 5.2/6.0 ms 38.5 MB/s 4 MB 10000 RPM 36 GB 5.5 ms 18-26 MB/s 8 MB RAID Max. Max. Sustained Cache Supported Device Bandwidth Bandwidth None MB/s None 0, 1, 0/200 MB/s None 0, 1, 1/528 MB/s 84-100 MB/s None None MB/s None 0, 1, 0/1, 160 MB/s 32 0, 1, 0/1, 320 MB/s 32 Cost $159 $165 $155 $550 $633 $815 Cost $25 $45 $500 $250 $499 $825 Cost/ GB $5.30 $5.50 $5.17 $15.11 $17.39 $22.39 Cost/ Device $6.25 $11.25 $62.50 $16.67 $33.27 $27.50
Table 1: Disk and Controller Price Comparison. Price figures are from www.dirtcheapdrives.com and www.buy.com 22 November 2000. From Table 1 we see that the price differential between SCSI and IDE is enormous. The lower price of IDE devices reflects ferocious competition and economies of scale. On balance, the IDE disks in the table have higher sustained bandwidths, but we see faster seek times and rotational speeds, and larger buffer sizes for SCSI disks. These differences largely reflect market forces rather than distinctions inherent to the technologies. Structure Controller Width Bus Bandwidth Current Bus 2001 Bandwidth 2004 Roadmap 2007 Cable Length Number of Devices Data Transfer Modes Command Concurrency Bus Concurrency Manageability IDE Interface to disks, CD-ROM On-board integrated controller 16-bit 3.3-100 MB/sec 100 MB/sec 150 MB/sec 300 MB/sec 600 MB/sec 46 cm (18 in) Supports only internal devices 2 per channel PIO or DMA Immature Tagged Queuing (Max 32 tags) Limited disconnect/reconnect S.M.A.R.T. SCSI Bus supporting many types of devices SCSI host bus adapter 8-bit, 16-bit, 32-bit 5-160 MB/sec 160 MB/sec 320 MB/sec 640 MB/sec ? 1.5-12 meters (12 meters with differential SCSI). Requires termination 15 per channel (wide SCSI) DMA Tagged Queuing (Max 256 tags) Disconnect/reconnect allows concurrent bus access S.M.A.R.T., SCAM
Table 2: Overview of IDE and SCSI Interface. The IDE features are from the ATA/ATAPI-5 standards (T13/T1321D Rev 2). The SCSI features are from the SCSI-2 and SCSI-3 standards (ANSI X3.131, NCITS.306, x3.270, x3.292, x3.301). Some features (e.g. S.M.A.R.T) are specific to the disk drive vendors and are not part of the standards [6, 35]. The future bus speed projections are from [5, 10].

From Table 2 we see several characteristics in the SCSI specifications that could lead to higher performance. SCSI has higher bus frequencies, wider bus widths, greater I/O concurrency (up to 256 outstanding requests), and more extensive disconnect/reconnect handling to reduce bus idle time. In addition, SCSI supports independent transfer rates for a mixture of slow and fast devices, whereas IDE runs all devices on the bus at the "least common denominator" i.e., the slowest bandwidth and data transfer mode of any device connected to the bus. The performance experiments in this paper show that factors such as disk concurrency, disk scheduling, file system design, and I/O parallelism can cause the observed system performance to differ significantly from what is suggested by a cursory examination of the disk drive specifications. For example, on a software development benchmark (SDET), the performance difference between IDE and SCSI disks is 22% using the default Unix Fast File System (FFS), but only 1% using the Soft Update enhancement to FFS. SCSI systems generally are considered to be more robust, manageable, and scalable than IDE systems, but many of the perceived reliability problems of IDE systems stem from early implementations that had defects in chipsets and device drivers [7], or are the consequence of improper cooling and operation [34]. Current IDE and SCSI disks should have similar reliability since they share common technology and components [1]. Moreover, storage vendors that sell both IDE and SCSI RAID systems (and thus have no vested interest in either product) note no major differences in disk failure rates between the two types of disks within the disk warranty period [16]. A SCSI disk typically has a 5 year warranty versus 3 years for an IDE disk, but rapid advances in disk technology render disks obsolescent before the expiration of the warranty period [22]. In terms of manageability, SCSI provides a richer command set that enables a user to query and configure device characteristics, and to control recovery from errors. Moreover, the SCSI physical interface supports a larger number of devices per bus and longer cables. RAID boxes that are constructed from IDE devices can obtain many of the advantages of the SCSI interface by exporting a SCSI interface to the host.
3 Measurement Methodology
This section describes our testbed for performance measurements, and the benchmark programs that we use to generate storage workloads.

Testbed

Our platform is a Dell OptiPlex PC equipped with an Intel D820LP motherboard, an Intel 1 GHz Pentium III processor, 512 MB RDRAM, and a 30 GB IDE system disk connected to the on-board IDE controller. For the IDE experiments, we use IBM Deskstar 75GXP disks, an Abit HotRod IDE controller with HPT 370 chipset, and a Raidweb (www.raidweb.com) IDE RAID array. For the SCSI experiments we use IBM Ultrastar 36ZX disks, an Adaptec 29160 host bus adapter (HBA), and a TSR-2200 (www.terasolutions.com) SCSI RAID array. Table 3 shows the detailed disk specifications. The IDE and SCSI disk settings are mostly comparable: we enable the read and write cache on both IDE and SCSI disks, and both disks support readahead. We enable disconnects and queue management (DQue and Queue Algorithm Modifier) [35] on the SCSI disk, but we are unable to ensure similar settings on the IDE disk as these parameters are not exposed by the IDE interface. The SCSI and IDE RAID arrays are comparable: 128 MB of SDRAM, 8 disks (IBM Deskstar75GXP or IBM Ultrastar36ZX) configured as RAID 5, and an Intel i960 processor. IBM disks are advantageous for experimentation because of detailed documentation for configuration parameters (e.g. Queue Algorithm Modifier) and internal measurement features (e.g. cache statistics). To confirm the generality of our findings, we repeat selected tests on Seagate ST318203LW and Maxtor DiamondMax Plus 40 disks, and on Tekram DC390U2W and Promise Ultra100 host adapters. We use a Verisys SV8160 SCSI bus analyzer (www.verisys.com) to capture I/O traces from the SCSI bus. The operating systems in our experiments are FreeBSD 5.020001108 and Windows NT 4.0 build 1381. To control disk concurrency (i.e., enable tag queuing and set number of tags), in FreeBSD we use the camcontrol command, and in Windows NT we use the Registry Editor. In FreeBSD experiments we control disk scheduling by marking requests with the BIO_ORDERED attribute to restrict request reordering. We cannot modify the disk scheduler behavior in Windows NT (we do not have the source code).

Model Capacity RPM Average Seek Time (read/write) Interface Interface Bandwidth Media Sustained Predictive Failure Analysis Buffer Size
IDE IBM Deskstar 75GXP 30 GB 7200 7.0 ms/8.0 ms ATA-MB/sec 37.0 MB/sec S.M.A.R.T. compliant 2 MB
SCSI IBM Ultrastar36ZX 18 GB 10000 4.9 ms/5.9 ms SCSI Ultra2 (Wide) LVD 80 MB/sec 29.5 MB/sec S.M.A.R.T. compliant 2MB
Table 3: Disk Specifications. All parameters are extracted from the respective disk drive manuals [6, 35].

Benchmarks

We choose our benchmarks to represent general-purpose computing and internet service environments. The goal of our evaluation is twofold. First, we seek to understand how IDE and SCSI perform under realistic I/O-intensive workloads. Second, we want to understand the impact of file system and storage system parameters on IDE and SCSI performance. We use two types of benchmarks. Our micro benchmarks quantify the performance of basic I/O operations like reads and writes. Our macro benchmarks measure general purpose programming workloads (SSH and SPEC SDET) and internet workloads (PostMark and NetNews). We run all macro benchmarks on a newly created file system to eliminate the effects of file system aging [29]. For the micro benchmarks, we conduct 10 experiments for each data point. Due to the duration of the macro benchmarks, we were only able to run 2-3 iterations of each experiment, but we observed consistent results across these runs. We computed standard deviations and investigated or re-tested anomalies. We verified that the durations of the macro benchmarks and sizes of the micro benchmarks are sufficient to prevent hitting in the buffer cache and disk cache across experiments. We begin with a set of micro benchmarks that read or write 10 MB from the disk under test, through the raw disk device to avoid the impact of the file system buffer cache [19]. The test forks off 128 children that each issue an 8KB I/O request, resulting in 128 outstanding I/O requests. We use semaphores and shared memory to coordinate the I/Os, and we verify that all 128 children are active concurrently via instrumentation and SCSI bus analysis. The sequential program accesses data stored sequentially. The random program accesses data stored at random addresses. The interleave test accesses data sequentially from two disk locations: one sequential stream starts at block zero, another sequential stream starts at the middle of the disk. The I/O requests from these two sequential streams are interleaved. This access pattern is common in some file systems like Microsoft Windows NTFS, which maintains log files at two disk locations (i.e. MFT and MFTmirror [30]). The SSH benchmark is proposed by Seltzer [27] as a replacement for the popular Andrew File System benchmark. It unpacks, configures, and builds a medium-sized software package (SSH). The unpack phase extracts a compressed tar archive containing the SSH source tree. It thus reads a large file sequentially and generates many subsequent small metadata operations. The config phase determines what features are available on the host operating system and generates makefiles. To do this, it compiles and executes many small test programs, causing many file system metadata operations. The build phase compiles and links the ssh executable. We run the three phases of the benchmark consecutively, consequently the config and build phases run with the file system cache warmed by the previous phases. The SPEC SDET benchmark [8] is designed to emulate a typical timesharing workload. It models a software development environment (e.g., editing, compilation, and various UNIX utilities) on a time-sharing host, and makes fairly extensive use of the file system. Although this benchmark models a time-sharing environment rather than today's client-server environment [27], it is nonetheless useful because it has tunable concurrency, and its basic operations are still representative of the software development workload.

The PostMark benchmark is designed to model the workload seen by Internet Service Providers under heavy load [13]. It is meant to model a combination of electronic mail, netnews, and web-based commerce transactions. It creates a large set of files with random sizes within a set range. The files are then subjected to a number of transactions like file create, delete, read and append. We run the benchmark with 25,000 files, 100 subdirectories, and 20K transactions, which results in a data size of about 400 MB. The NetNews benchmark is developed by Karl Swartz to simulate the workload of a NetNews server [33]. It creates a large number of files representing news articles, and deletes old articles by replaying traces that were collected from a live server. This benchmark differs from the other benchmarks in that it has very little locality of reference, and its large data set (2 GB) overwhelms the file system buffer cache [27].

4 Performance Results

We first compare the IDE drive with the SCSI drive on various benchmarks. Our results indicate that IDE is faster on a sequential workload, but not on a random workload. We then analyze the results and study four factors that affect performance: concurrency (tagged queuing), scheduling, file system features, and parallelism (with multiple disks). We find that although IDE disks are slower on the random workload, the performance deficiencies can be mitigated with judicious system design choices.

Single Disk Performance

Table 4 compares the performance of IDE and SCSI disks on the various benchmarks, and computes the percentage differences in the last column. We use the Unix fast file system (FFS) [18] for the application benchmarks. In this table we use a tag setting of 32 in the driver. Benchmarks Read Sequential Micro benchmark Interleave Random Write Sequential Micro benchmark Interleave Random SDET 1 job 5 jobs 10 jobs 20 jobs SSH PostMark NetNews Table 4: SCSI versus IDE Performance. The micro benchmark results indicate that the IDE disk is about 33% and 40% slower on random writes and reads, respectively. This is consistent with the disk specifications in Table 3: a small random I/O operation is dominated by the seek time [35, 6], and the random I/O performance difference between the IDE and SCSI disks is similar to the ratio of disk seek times (36% and 43% for read and write, respectively). The IDE disk is significantly faster (40-100%) than the SCSI disk on benchmark workloads with highly sequential access patterns: this result is also consistent with Table 3. On the application benchmarks, the SCSI disk is 18% (SSH) to 36% (NetNews) faster than the IDE disk. Since these benchmarks have a large number of synchronous writes to random addresses, and these experiments use the Unix FFS file system [27], the faster performance of the SCSI disk is consistent with its faster seek time. Because the SSH benchmark is less I/O bound, it shows a smaller advantage for SCSI. IDE 31.6 MB/sec 23.5 MB/sec 1.5 MB/sec 27.1 MB/sec 19.2 MB/sec 1.4 MB/sec 10.1 sec 78.2 sec 178.5 sec 377.1 sec 88.5 sec 502 sec 1100 sec SCSI 15.8 MB/sec 17.4 MB/sec 2.5 MB/sec 19.2 MB/sec 16.8 MB/sec 2.1 MB/sec 12.3 sec 63.8 sec 129.4 sec 283.0 sec 74.9 sec 387 sec 809 sec % Perf. Diff -100% -35% 40% -41% -14% 33% -18% 23% 38% 33% 18% 30% 36%

Factors Affecting Disk Performance
In Section 4.1 we have seen that the IDE disk performs well for sequential access, but not as well as the SCSI disk for random access. We now investigate the effectiveness of four approaches that attempt to improve the random-access performance of the IDE drive. In brief, these approaches are as follows. In Section 4.2.1 we examine how the random-access performance varies depending on the degree of concurrency (tagged queuing). I/O concurrency enables the drive to reorder requests to reduce the seek time. Our results indicate that a tag size of 4 appears adequate for a single disk for these application benchmarks, so IDEs maximum tag limitation of 32 (versus 256 for SCSI) does not impair performance. In Section 4.2.2 we investigate whether I/O scheduling in the host is an adequate substitute for tagged queuing and scheduling in the disk, as suggested by prior disk scheduling studies [26, 12]. If we compare ideal conditions for the host-based elevator scheduling (thousands of dirty pages in the buffer pool) with ideal conditions for disk scheduling (tagged queuing with concurrency > 32), the random I/O micro benchmark indicates that disk scheduling is significantly more effective than host scheduling. But the application benchmarks show little performance difference between host-based and disk-based I/O schedulingthese benchmarks do not generate sufficiently high concurrency to favor either scheduler. In Section 4.2.3 we evaluate the impact of two file system enhancements, Soft Updates (which reduces synchronous metadata writes by careful write ordering) and Journal file system (which performs sequential log writes for metadata updates). The results indicate that, when running benchmarks on the Soft Updates or Journal file systems instead of FFS, the IDE and SCSI drives have similar performance (under certain conditions described in Section 4.2.3). We use a novel low-level SCSI trace approach to explain the qualifying conditions. In Section 4.2.4 we explore using disk arrays [21] with random I/O workloads. We present results obtained on hardware SCSI and IDE RAID arrays, and on the Vinum software RAID [15] on FreeBSD. Our measurements indicate that IDE RAID hardware is now faster than host-attached SCSI disks or entry-level SCSI RAID arrays. We now elaborate on these topics.

4.2.1 Disk Concurrency

Table 5 and Table 6 summarize the performance of SCSI and IDE disks for various tag, scheduler, and file system settings. We first study disk concurrency using the default FFS file system, with I/O scheduling enabled in both the disk drive and the kernel. We observe from Table 5 that there is no improvement in performance for a sequential workload with higher concurrency (i.e. larger number of tags). This is expected since sequential I/O is already sorted in an optimal manner. Concurrency improves the performance of SCSI disks on random I/O micro benchmarks by 25-50%, but for most application benchmarks by only 3-5%. We observe very little improvement in performance beyond 4 tags, and no improvement in performance beyond 64 tags. To confirm that the increase in tags does result in higher concurrency at the disk, we measure the average queue depth in the SCSI disk using a SCSI bus analyzer. With 64 tags, we observe that the average number of outstanding requests at the disk is 60 for reads and 46 for writes, yet with 4 tags the disk has already reached its peak rate (220 requests/sec for 8KB random I/O). For the IDE disk, tagged queuing gives improvements of 15-40% on random reads, and no improvement on random writes. This latter result is suggestive of problems with IDE tagged queuing, which is investigated in more detail in Section 4.2.2. Even with tagged queuing, IDE random read performance is nearly 50% worse than the corresponding SCSI performance. We conclude that tagged queuing in its current state is insufficient to overcome IDEs larger seek latencies.

IDE Random 1.3 1.6 1.5 (Not Supported in IDE) 1.9 2.0 2.0 (Not Supported in IDE) 24.4 24.7 24.5 (Not Supported in IDE) 1.8 1.9 2.5 (Not Supported in IDE) 0.9 1.1 1.3 23.0 24.7 25.8 10.6 10.5 10.5 1.1 1.1 1.1 1.3 1.6 1.5 24.3 24.3 26.7 18.2 17.0 18.1 1.4 1.4 1.4 0.9 1.1 1.3 23.3 24.2 24.5 10.7 10.7 10.5 1.1 1.1 1.1 Write Sequential Interleave 25.1 18.5 26.7 17.4 27.1 19.2 Random 1.4 1.4 1.4

No. of Tags

Scheduler
Read Sequential Interleave 30.8 24.8 31.9 24.7 31.6 23.5

Disk Only

31.4 32.7 31.6

Host Only

30.7 32.4 29.4
none None None None 64 128

32.4 32.2 31.1

Read Sequential Interleave 16.9 21.0 15.0 18.6 15.8 17.4 16.0 15.8 15.8 15.2 14.4 1.8 14.1 1.9 14.4 9.4 14.1 8.9 14.8 8.9 16.5 21.0 14.7 18.9 13.8 15.0 14.1 11.1 14.3 11.1 15.3 1.8 14.4 1.4 14.7 1.5 14.6 1.5 14.5 1.5 Random 1.6 2.2 2.5 2.4 2.4 1.1 1.5 2.2 2.3 2.3 1.6 1.8 1.7 1.7 1.7 1.1 1.2 1.2 1.2 1.2 Random 1.6 2.0 2.1 2.1 2.1 1.0 1.6 1.8 1.9 1.9 1.6 1.6 1.6 1.5 1.5 1.0 1.0 1.0 1.0 1.0
Write Sequential Interleave 21.4 19.0 19.6 17.8 19.2 16.8 19.1 15.8 19.1 15.6 19.4 0.9 18.2 1.7 19.3 11.8 19.2 10.5 19.0 10.4 21.1 18.7 19.7 17.8 19.1 12.3 18.2 8.9 18.4 9.0 19.7 0.9 18.3 0.9 17.8 0.9 18.2 0.9 17.9 0.9
Table 5: Micro benchmark Results with Different Tag and Scheduler Settings. Results are reported in Mbyte/sec. Shaded columns under IDE contain questionable results that may reflect bugs in queued DMA features of IDE diskssee text.

Number Of Tags

none 8 32/64 none 8 32/64 none 8 32/64 none 8 32/64
Unix FFS (Sync Metadata and Async Data Update) IDE SCSI SDET SSH NetNews PostMark SDET SSH NetNews PostMark 376.1 86.500 292.2 80.406 (Not Supported by Driver) 282.7 80.383 374.5 86.502 283.0 80.387 399.0 88.571 348.2 83.485 (Not Supported by Driver) 302.8 81.407 399.9 87.573 291.6 81.402 378.5 87.500 295.8 81.405 (Not Supported by Driver) 287.2 81.402 380.9 87.501 301.2 81.431 471.8 94.573 345.6 83.485 (Not Supported by Driver) 333.7 83.471 460.2 95.572 338.1 83.471
Soft Updates (Async Metadata and Data Update) IDE SCSI SDET SSH NetNews PostMark SDET SSH NetNews PostMark 19.8 63.199 20.0 64.181 (Not Supported by Driver) 19.5 63.158 19.9 66.202 20.0 63.166 20.5 64.250 19.4 65.248 (Not Supported by Driver) 20.3 64.182 20.2 67.252 20.4 64.173 19.9 63.200 19.8 63.174 (Not Supported by Driver) 20.2 64.172 20.3 66.201 19.7 63.208 19.6 68.249 21.5 65.249 (Not Supported by Driver) 20.7 65.245 21.7 71.249 19.8 65.246

Table 6: Application Benchmark Results. All results are seconds of elapsed time. We vary the number of tags, disk or host scheduler, and type of file system. Due to space constraints we report SDET results only for a script concurrency of 20, and only the total elapsed time for SSH. Note that the maximum number of tags for the IDE disk is 32, versus 64 for the SCSI disk.

4.2.2 Disk Scheduling

Scheduling may be performed at the disk, which has intimate knowledge of the disk geometry. Alternatively, scheduling may occur within the device driver or kernel, either of which may have access to a larger pool of schedulable requests in the form of dirty blocks residing in a buffer cache. Throughout this paper we refer to the former as disk scheduling, and the latter as host scheduling. We first make the obvious observation that it is crucial to have some type of scheduler (disk, host or both) in the system. From Tables 5 and 6, we see that for many of the benchmarks, having both schedulers provides a substantial benefit over no scheduler, for both SCSI and IDE disks. We now compare the performance of host and disk schedulers. We observe from Table 5 and 6 that when concurrency is below 32, the host scheduler consistently out-performs the disk scheduler. This is expected, because the host scheduler is working on a larger pool of I/O requests (maximum of 4096 versus 32 on disk). However, when the disk has sufficient concurrency, it can outperform the host scheduler. For example, we see from Table 5 that on random I/O, the SCSI disk scheduler outperforms the host scheduler by 13-35% when the concurrency exceeds 32. In the SCSI application benchmark results in Table 6, we see less drastic differences: the disk scheduler outperforms the host scheduler for NetNews by 12%. (SSH and SDET show less improvement as they are less I/O bound.) On PostMark and NetNews, the performance gap is more obvious on the Soft Update file system than on FFS (20-27% versus 3-12%). This is because synchronous I/O dominates the application performance on FFS, whereas the Soft Update file system exploits a large pool of asynchronous buffers in both the host and disk schedulers. A non-intuitive result is that the host schedulers performance on SCSI disk decreases with increasing number of tag (e.g. random and interleave macro benchmarks). This is due to a complex interaction between the host scheduler and disks tag queuing mechanism. We explain a simple scenario in Figure 1, which shows a host scheduler with a buffer size of 2 scheduling I/O requests. The shaded boxes represent new requests, which alternate between the interleaved addresses. Figure 1a shows that when there is no tagged queuing, the disk sees more sequential requests (i.e. 100, 101, 102, N+100, N+101, N+102.). This schedule incurs less costly disk seeks than that generated by a host scheduler with tagged queuing enabled (see Figure 1b). The latter schedule incurs more disk seeks since it alternates between interleaved addresses (i.e. 101, N+100, 102, N+101.). In general, it is crucial that tag queuing is only enabled when the disk scheduler is active. The results for disk scheduling in an IDE disk are puzzling. We fail to see the expected performance increase of the interleaved micro benchmarks with increasing numbers of tags under disk scheduling. Also, there is no performance difference between disk scheduling and no scheduling. These results are indicative of problems in the current implementation of tagged queuing DMA, either in FreeBSD or in the disk firmware. Instrumentation shows that the disk is not performing any scheduling for interleaved or random writes. In the case of interleaved reads, traces indicate that requests are initially scheduled by the disk, but revert to their original interleaved ordering after a few hundred have been satisfied. Note to referees: We are working with the FreeBSD IDE driver author to locate the source of this problem (i.e. driver, IDE controller or IBM disk?) and expect to have conclusive results in the final version of this paper. Because our experiments use the default I/O scheduler in FreeBSD, our results do not reflect the full potential of host scheduling. Scheduling algorithms that utilize detailed knowledge of physical data layout on disk, and that accurately track the disk arm position, can outperform BSD's elevator algorithm [12, 26, 36]. Time T1 T2 T3 T4 T5 T6 Disk Addresses RequestServed N+102 N+N+100 N+101 N+N+101 N+N+102 N+102. (a) Host Scheduler, no Tagged Queuing Disk Addresses RequestServed 100,101 N+N+100,N+101 N+101,103 N+N+102,N+103 N+103,105 N+N+104,106. (b) Host Scheduler, # of Tag=2

Figure 1: I/O Schedule as Seen by the Disk During an Interleave Micro Benchmark. 8
4.2.3 File System Designs
Table 6 presents application benchmark results comparing FFS with Soft Updates on both IDE and SCSI disks. We observe that on FFS, SCSI consistently out-performs IDE (15-47%) on most application benchmarks (except SSH which is less I/O bound). On the Soft Updates file system, SCSI and IDE disks have comparable performance for most benchmarks except NetNews: The NetNews buffer footprint exceeds the system buffer pool, so the application is occasionally blocked while the buffer pool is cleaned. This cleaning causes synchronous random writes, a workload for which the SCSI disk has significantly better performance. We also note that on the Soft Updates file system, higher concurrency settings increase the performance advantage of SCSI over IDE (e.g., from 10% to 22% on PostMark). This is mainly due to the buggy IDE tagged queuing, so we expect this advantage to diminish in the future. On balance, Soft Updates helps compensate for the slower seeks of the IDE disk. We now explore the performance of Soft Updates and journaling in more detail by examining a lowlevel trace of physical disk accesses during benchmark runs, as recorded by a SCSI bus analyzer. We limit our discussion to the PostMark benchmark due to space constraints, but our observations are similar for the SDET and NetNews benchmarks. Figure 2 shows the sequence of disk accesses during a PostMark run on three file systems: FFS, Soft Updates, and NTFS. Each point indicates the time and corresponding disk address of a physical disk write. Figure 2a shows the SCSI trace during a PostMark run on FFS. The PostMark benchmark has 3 phases: create files, run transactions, and delete files. The create phase touches inodes in many cylinder groups [19], thus we see the gradual march from the first to Nth cylinder group, where N is determined by the data set. The run phase updates data created during the create phase, and thus we see disk activity from the first to the Nth cylinder group. Because the run phase also creates files, we see additional activity above the Nth cylinder group (i.e. disk address from 180000-240000). The vertical lines in the run phase represent update daemon activities, occurring once every 30 seconds [19]. These writes are asynchronous and are sorted by the host scheduler in ascending order to minimize disk seeks, and appear as vertical lines due to the compressed time scale. The horizontal lines in Figure 2a represent synchronous metadata updates for each cylinder group. These synchronous writes, spread over many cylinder groups, make random writes the dominant factor. Thus, for this workload on FFS, IDE is much slower than SCSI. Figure 2b shows the same experiment on the Soft Updates file system. This file system has very few synchronous metadata writes [27], and thus we do not see any horizontal lines. Almost all writes are asynchronous and can be scheduled nicely (thus the straight vertical lines). The delete phase in the Soft Update file system is considerably faster than on FFS, because most files are created and deleted entirely within the buffer cache, so relatively little physical disk I/O occurs [27]. With writes not being a factor, the determining factor for the Soft Update file system is concurrency (i.e. how fast the disks absorb the sorted asynchronous writes). IDE and SCSI are somewhat comparable with no tagged queuing, but current IDE systems improve less than SCSI does when tagged queuing is enabled, as seen in Table 6. Our measurements show that IDE is faster (10%) than SCSI on the PostMark benchmark when running on the Windows NTFS file system. NTFS is a journaling file system, so its metadata write activity is largely sequential. Consequently, IDE has comparable performance to SCSI, as seen in Figure 2c. We observe that the writes are clustered in 3 regions. The middle region contains asynchronous writes to the file data. The two horizontal lines in Figure 2c represent sequential writes to the log files in the Master File Table (MFT) and the MFT mirror [30] (magnified view in Figure 2d). The MFT is located near the start of the disk, and the MFT mirror is located in the middle of the disk. Because the sequential writes alternate between these two regions, the I/O accesses resemble the interleaved I/O modeled in Table 5. We know that SCSI and IDE have comparable performance for that access pattern. In summary, we find that file system design has great potential to enable IDE to achieve performance comparable to SCSI. In journaling or log-structured file systems or with workloads dominated by sequential or interleaved writes, IDE performs comparably to SCSI. IDE also performs well under Soft Updates. Disregarding tagged queuing, IDE achieves 80% of SCSIs performance for NetNews and 90% for PostMark, and would be comparable to SCSI in this environment if IDEs tagged queuing performed as expected.

PostMark SCSI Trace (FreeBSD, FFS)
PostMark SCSI Trace (FreeBSD, Soft Updates)

Create Files

50000 0

300 400

Transactions

Delete Files

250000

200000

150000

100000

Disk Address (Sectors)

Time (seconds)

PostMark SCSI Trace (Windows NT, NTFS)

1.794E+07

PostMark MFTMirror Trace (Windows NT, NTFS)
Create Files Transactions

1.793E+07

1.792E+500
PostMark MFT Trace (Windows NT, NTFS)

(c) (d)

Figure 2: SCSI Trace of PostMark Benchmark. The I/O traces are collected from the SCSI bus using a SCSI bus analyzer. 10

4.2.4 Parallelism

In this section we explore the performance of disk arrays. The software disk array is configured as RAID 0 (striping only, no parity computation) since a RAID 5 configuration would result in a bottleneck caused by parity I/Os, masking the IDE vs. SCSI performance issues that we are investigating. The hardware array and the software array both use a 64KB stripe size. Software Disk Array (Vinum) IDE SCSI % Faster 6.9 23.9 -246% 7.2 23.5 -226% 5.4 4.2 22% 303.1 244.9 -19% 86.8 78.3 -10% -23% 16% 16 16.9 6% 62.5 64.1 3% -26% 30% Hardware Disk Array IDE SCSI % Faster 15.1 35.2 -133% 15.4 25.8 -68% 3.8 3.3 13% 21.5 43.1 100% 64.6 65.1 1% 410.0 326.0 -20% 57.0 106.0 86% 16.5 16.2 -2% 63.2 63.3 0% 309.0 301.0 -3% 49.0 82.0 67%
Write Micro benchmark (MB/sec) FreeBSD Unix FFS (seconds)
FreeBSD Soft Update File System (seconds)
Sequential Interleave Random SDET SSH NetNews PostMark SDET SSH NetNews PostMark
Table 7: SCSI versus IDE Disk Array Performance. The hardware disk array has 8 disks configured in RAID5 with 7+1 spare. The software disk array has 4 disks configured in RAID 0 (striping only without redundancy). The % Faster column compares IDE versus SCSI performance. Table 7 compares the performance of software and hardware disk arrays for the write micro benchmark and for the application benchmarks running on the FFS and the Soft Updates file systems. We omit reporting the read micro benchmarks and other variables (Windows NT, tag settings) as they merely reinforce the results. The write micro benchmark results indicate that SCSI is faster on sequential I/O, but slower on random I/O. These results contradict the single disk results in Table 5. These differences are largely due to system design factors. In particular, both the hardware and software IDE disk arrays have lower bus contention because they use 1 bus per IDE disk, whereas the SCSI disk array has one (Vinum software array) or two (hardware RAID) SCSI buses in total. The IDE hardware RAIDs slower sequential performance may reflect an inefficient I/O scheduling algorithm, as other vendors (e.g. 3ware and JetStor) have demonstrated much greater sequential bandwidth. The micro benchmark results provide clues into the macro benchmark results. We first look at the software IDE array. The software IDE array is mostly slower when running on the FFS file system. Both SDET and SSH have a small buffer footprint, and their I/Os are smaller than the stripe unit (2KB versus 64KB) and tend to concentrate on several cylinder groups in a single disk. Thus the benchmark workload degenerates into random I/O on a single disk, so the SCSI array performs better. The single disk bottleneck can be mitigated with NVRAM to absorb metadata updates for hot cylinder groups. Both hardware disk arrays have large (128 MB) buffer caches, thus the remaining performance obstacle is random writes. The software IDE array is faster than the SCSI array on configurations that have large amounts of asynchronous random writes, thus it performs better on the SDET, SSH, and PostMark benchmarks when using the Soft Update file system. NetNews buffer footprint exceeds the system buffer pool and thus is dominated by metadata writes (both random and interleaved), thus it exhibits the worst performance under both file system configurations. Since the IDE hardware disk array has faster random writes, it performs better on most benchmarks. We can tailor a disk array to take advantage of IDE technology. In particular, IDE controllers are significantly less expensive than SCSI controllers (e.g. the Promise PDC20267 chip is at least 6 times less expensive than Adaptecs 78xx controller), so one can eliminate I/O bus contention in an IDE array by using a separate bus for each disk. The disk array can also export a SCSI interface to the host to overcome the lack of concurrency at the IDE interface.

Disk Performance Studies

Kerns provides a detailed introduction to SCSI tagged queuing, and assesses the importance of this capability via micro benchmark studies [14]. His results suggest that a small number of tags (<32) is sufficient to achieve good performance. Besides concurrency, disk scheduling is also crucial in reducing seek latencies [26, 12]. Scheduling may be performed at the disk, which has intimidate knowledge of the disk geometry, or within the kernel, which may have a large pool of schedulable requests. The tradeoff between these two approaches is studied in detail in [26], where the authors show the merits of host scheduling. Recent work on extensible kernels also advocates fine-grain control of disk resources for maximum flexibility and adaptivity (e.g., Nemesis [2]). The file system design has a significant effect on disk performance as it determines the data layout and physical access patterns. Unix FFS [18] statically allocates regions of the disk for inodes, and tries to locate data and metadata in rotationally optimal positions. However, metadata operations still incur significant seek and rotational latencies [9]. Moreover, FFS typically writes its metadata synchronously to disk to maintain file system integrity. Many recent studies reduce synchronous and non-sequential accesses at the file system (see [27] for an excellent introduction). In this paper we evaluated two modern file systems. Soft Updates [9] tracks dependencies between metadata blocks such that metadata writes may be delayed, thus significantly reducing the number of synchronous I/Os and allowing for more effective scheduling. A journaling file system writes its metadata sequentially to disk, greatly reducing disk seeks [30].

6 Conclusions

We have presented a thorough examination of IDE and SCSI performance through a combination of micro benchmarking and macro benchmarking. The principal independent variables for the benchmarking are workload factors such as sequentiality, locality, and read/write ratio, and system aspects such as I/O concurrency (as enabled by tagged queuing), disk scheduling in the host or on the disk, file system features such as journaling and soft updates, and I/O parallelism via disk arrays. The IDE disks that we measured are generally faster than the SCSI disks for sequential I/O, but slower for random I/O. Our experimental results indicate that we can mitigate the random I/O handicap of IDE by appropriate choices with respect to the system aspects mentioned above. We also measured the performance of software and hardware RAID arrays built from IDE disks and from SCSI disks. The IDE and SCSI arrays exhibit similar performance. We note several techniques that may give substantial additional performance improvements to the IDE array.

7 Acknowledgements

We would like to thank Liddy Shriver for suggesting that we compare host and disk scheduling. Along with Liddy, Margo Seltzer did the initial work in this area and allowed us to follow in her tracks. We are indebted to Keith Smith for help in acquiring and running the benchmarks.

8 References

7 3ware. www.3ware.com P. Bosch. Mixed Media File Systems. PhD thesis. University of Twente, 25 June 1999. D. Cardenas, J. Catena, SCSI vs. IDE: Bus Mastering for DAWs, Audio Amiga Report, 2000. http://www.txconnect.com/home/ignot/article/scsi_ide.htm L. Chung, J. Gray, B. Worthington, R. Horst, Windows 2000 Disk IO Performance, Microsoft Research Technical Report MS-TR-2000-55, June 2000. M. Delsman, The Future of SCSI, http://www.scsita.org/aboutscsi/pub/PCDC9905_RoadMap.pdf Deskstar 40GV & 75GXP Hard Disk Drive Specifications, Version 1.2, IBM Corp. May 2000. P. Den Haan, Enhanced IDE FAQ and Utilities, http://thef-nym.sci.kun.nl/~pieterh/storage.html
S. Gaede, Perspectives on the SPEC SDET Benchmarks, http://www.spec.org/osg/sdm91/sdet/index.html. G. Ganger, Y. Patt, Metadata Update Performance in File Systems, OSDI Conf Proc., pp. 49-60, Monterey, CA, Nov. 1994. K. Grimsrud, Serial ATA Overview, http://serialata.org/F9pp.pdf Highpoint Technologies, Inc. www.highpoint-tech.com D. M. Jacobson, J. Wilkes, Disk scheduling algorithms based on rotational position, HP Laboratories technical report HPL-CSP-91-7rev1, Feb 1991 (revised Mar 1991) J. Katcher, PostMark: A New File System Benchmark, Technical Report TR3022. Network Appliance Inc, Oct. 1997. R. Kerns, "SCSI command tag queuing and cached disk performance", Storage Management, 6(11), pp. 18-11, Nov. 1998. G. Lehey, The Vinum Volume Manager, Proceedings of the FREENIX Track: 1999 USENIX Annual Technical Conference, Monterey, CA, June 1999. G. Leyzarovich of Advanced Computer & Network Corp and P. Neff of RaidWeb Inc. Personal Communications. T. Martin, A. Scholl, SCSI Remains the I/O Interface of Choice for Workstations: An Analysis Comparing SCSI and Ultra DMA, SCSI Trade Association white paper, Jan 1998. http://www.scsita.org/whitepaper/SCSIUDMA.pdf M. McKusick, W. Joy, S. Leffler, R. Fabry, A Fast File System for Unix, ACM Trans. On Comp. Sys. 2(3), pp. 181-197, Aug. 1984. M. McKusick, K. Bostic, M. Karels, J. Quarterman, The Design and Implementation of the 4.4BSD Operating System. Addison-Wesley, 1996. G. Murakami. http://www.research.att.com/~gjm/linux/ide-raid.html D. Patterson, G. Gibson, R. Katz, A Case for Redundant Arrays of Inexpensive Disks (RAID), Proceedings of the SIGMOD Conference, June 1998. PC Guide. http://www.pcguide.com Promise Technologies, Inc. www.promise.com E. Riedel, C. Ingen, J. Gray, Sequential I/O on Windows NT: Achieving Top Performance, Microsoft Research Technical Report MSR-TR-97-34, 1997. F. Schmidt, The SCSI Bus & IDE Interface, Protocols, Applications & Programming. AddisonWesley, 1998. M. Seltzer, P. Chen, J. Ousterhout, Disk Scheduling Revisited, USENIX Winter Conf. Proc., pp. 313324, Washington, DC, Jan. 1900. M. Seltzer, G. Ganger, M. McKusick, K. Smith, C. Soules, C. Stein, Journaling versus Soft Updates: Asynchronous Meta-data Protection in File Systems, USENIX Conf. Proc., pp. 71-84, San Diego, CA, June 2000. A. Silberschatz, P. Galvin, Operating System Concepts. Addison-Wesley, 1994. K. Smith, M. Seltzer, File System Aging Increasing the Relevance of File System Benchmarks, Sigmetrics Conf. Proc., pp. 203-213, Seattle, WA, June 1997. D. Solomon, Inside Windows NT, Second Edition. Microsoft Press. 1998. N. Stam, SCSI vs. EIDE: The Real Story, PC Magazine Reports, July 1996. http://www.zdnet.com/pcmag/pclabs/report/r960702a.htm M. D. Stone, Mixing IDE and SCSI Hard Disks, PC Magazine Reports, Nov 1999. http://www.zdnet.com/filters/printerfriendly/0,6061,2354187-50,00.html K. Swartz, The Brave Little Toaster Meets Usenet, LISA 96, pp. 161-170, Chicago, IL, Oct. 1996. N. Talagala, D. Patterson, An Analysis of Error Behavior in a Large Storage System, 1999 Workshop on Fault Tolerance in Parallel and Distributed Computing, Jan 1999. Ultrastar 36ZX and 18LZX Functional/Hardware Specification, Version 2.01, IBM Corp., Sep. 1999.

HPT370 RAID Controller Guide
1. 1-1. 1-2. 1-3. 1-4. 2. 2-1. 2-2. 3. 3-1. 3-2. 3-3. 3-4. Introduction of RAID..1 What is RAID?..1 Why RAID?..2 The RAID levels..2 Which RAID level should I use?.4 The features of RAID on this motherboard.5 Setting up RAID on this motherboard..5 The BIOS setting menu.6 Software installation..10 DOS..10 Windows 9x..10 Windows NT 4.0.12 Windows 2000..14
Copyright and Warranty Notice:
The information in this document is subject to change without notice and does not represent a commitment on part of the vendor, who assumes no liability or responsibility for any errors that may appear in this manual. No warranty or representation, either expressed or implied, is made with respect to the quality, accuracy or fitness for any particular part of this document. In no event shall the manufacturer be liable for direct, indirect, special, incidental or consequential damages arising from any defect or error in this manual or product. Product names appearing in this manual are for identification purpose only and trademarks and product names or brand names appearing in this document are the property of their respective owners. This document contains materials protected under International Copyright Laws. All rights reserved. No part of this document may be reproduced, transmitted or transcribed without the expressed written permission of the manufacturer and authors of this document. If you do not properly set the settings of this product, causing this product to malfunction or fail, we cannot guarantee any responsibility.

MN-171-2K0-39 Rev. 2.00

Introduction of RAID
Thank you for purchasing ABITs latest motherboard with RAID function. Please read this guide as a reference for setting up the RAID BIOS and installing the driver software of this motherboard. This motherboard uses the HighPoint 370 controller which allows for RAID.

1-1. What is RAID?

RAID (Redundant Array of Inexpensive/Independent Disks) technology was developed to offer a combination of outstanding data availability, excellent performance, and high capacity that one single disk drive can not meet up with. A RAID array is defined as two or more disks grouped together to appear as one single device to the host system, which can tolerate the failure of a drive without losing data, and which can operate independently from each other. To manage MTBF (Mean Time Between Failures) and prevent any single drive failure causing data loss within an array, UC Berkeley scientists proposed five types of redundant array architectures, defining them as RAID levels 1 through 5. Each RAID level has its own strengths and weaknesses, and is well HPT370 RAID Controller Guide 1
suited for certain types of applications and computing environments. RAID 1, RAID 3 and RAID 5 of these five types are commonly used. RAID 2 and RAID 4 do not offer any significant advantages over these other types. RAID 3 is designed for single-user or data-intensive environments, such as imaging or data acquisition that access extremely large sequential records. This leaves RAID 1 and RAID 5 as the RAID levels is applicable for networked and transaction processing-based environments utilizing NetWare, Windows NT, Unix, and OS/2. In addition to these five redundant array architectures, it has become popular to refer to a non-redundant array of disk drives as RAID 0 array.

1-2. Why RAID?

Data security is a very important issue for system administrators. They have to adopt efficient methods of data protection to guard against potential losses due to drive failures. Tape-based backups are used to be one solution for data security, but this method is becoming a task more difficult. Slow, cumbersome tape backup solutions lose their effectiveness for servers and workstations. RAID technology is another solution for data security. There are a number of factors responsible for the growing adoption of arrays for critical network storage. Because todays applications create larger files, the need for network storage has proportionately increased. To accommodate expanding storage requirements, users are adding disk drives --- raising the probability of drive failures. In addition, the development of CPU speed has exceeded data transfer rates to storage media, causing I/O bottlenecks for networking application. RAID technology overcomes these challenges by providing a combination of outstanding data availability, extraordinary and highly scalable performance, as well as high capacity. RAID provides real-time data rebuild when a disk drive fails, increasing system uptime and network availability, while protecting against the loss of data. Multiple drives working together also increases system performance.

1-3. The RAID levels

RAID Level 0:
. Block D Block C Block B Block A
Striped Disk Array without Fault Tolerance
RAID 0 is typically defined as a non-redundant collection of striped disk drives. It doesnt provide data protection but it offers very high data throughput, especially for large files. RAID 0 does not deliver any fault tolerance. All data is lost if any drive in the array fails. It is intended for noncritical data requiring high performance. Simply put, RAID 0 splits the information in two, with half of the information going to each hard disk. Thus, performance is quickened by this approach.
Block B Block D Block F etc
Block A Block C Block E Block G

Disk 0

Disk 1
ABIT Computer Corporation

RAID Level 1

Block D Block C Block B Block A

Mirroring and Duplexing

RAID 1 provides 100% redundancy by mirroring one drive to another one. In the event of a disk drive failure, the array controller will automatically switch the read/write activity to another drive. Each individual drive can execute simultaneous read operations. Mirroring thus doubles the read performance of a single drive and leaves the write performance unchanged.
Block A Block B Block C Block D

Block A

! Mirror

Block B Block C Block D

RAID 1 is a good entry-level redundant system, since only two drives are required. However, the cost of RAID 1 is higher because one drive has to be used to store duplicate data.

RAID Level 2

Disk Striping with error-correction code (ECC)
RAID 2, which uses Hamming error correction codes, is intended for use with drives which do not have built-in error detection. Because the check method of Hamming code is very complicated, and more than one drive is required to store ECC information, RAID 2 offers no significant advantages over RAID 3.

A0 B0 C0 D0

A1 B1 C1 D1

A2 B2 C2 D2

Hamming Code

Disk 2

RAID Level 3
Parallel transfer with parity
RAID 3 uses a separate drive to store parity and stripes data on a byte-by-byte basis across all of the data disks in the array.
Stripe 2 A2 B2 C2 D2 Stripe 0, 1, 2 Parity A Parity B Parity C Parity D Parity

Stripe 0 A0 B0 C0 D0

Stripe 1 A1 B1 C1 D1
Because each I/O accesses all drives in the array, RAID 3 does not support multiple, simultaneous read/write requests. It is optimized for large, sequential data requests.

RAID Level 4

Independent Data disks with shared parity disk
RAID 4 is identical to RAID 3 except the block level stripes are used.
Block 0, 1, 2 Parity A Parity B Parity C Parity D Parity

Block 0 A0 B0 C0 D0

Block 1 A1 B1 C1 D1

Block 2 A2 B2 C2 D2

RAID 4 supports multiple simultaneous read requests. However, since all write operations require that parity data to be updated each time, they can not be overlapped. And so the RAID 4 offers no significant advantages over RAID5.

RAID Level 5

Independent Data disks with distributed parity blocks
RAID 5 also stripes data at a block level across several drives. But it distributes parity among the drives, this avoids the write bottleneck caused by the single dedicated parity drive. Each drive takes turns storing parity information for a different series of stripes. RAID 5 can execute read/write to disk drives either in parallel or independently.

A Block A0 A1 AParity

B Block B0 BParity B3

C Block CParity C2 C3

D Block 0 Parity D1 D2 D3
1-4. Which RAID level should I use?
Many different disk array configurations are possible, depending on end-user requirements and the goals of the manufacturer. Each controller design has a different functionality to accomplish specific performance and data availability goals. Therefore, no individual RAID level is inherently superior to any other. Each of the five array architectures is well suited for certain types of applications and computing environments. The follow table summarizes the strengths and weaknesses of each RAID level. RAID Min. No. Level of Drives RAID RAID Description

"

Characteristics / Strengths
" " " " "

Weaknesses

Striped Disk Array without Fault Tolerance Mirroring and Duplexing
Highest I/O Performance Very simple design Easy to implement 100% redundancy of data Twice the Read transaction rate of a single disk, same Write transaction rate as single a disk Simplest RAID storage subsystem design
No redundancy One drive fails, all data is lost High redundancy cost overhead

RAID 2

Not used in LAN
Disk Striping with errorcorrection code (ECC) Parallel transfer with parity

RAID 3

" " " "
Previously used for RAM error environments correction (known as Hamming Code) and in disk drives before the use of embedded error correction Very high Read data transfer rate Very high Write data transfer rate Excellent performance for large, sequential data requests Low ratio of ECC (Parity) disks to data disks means high efficiency

No practical use

RAID 4
Independent Data disks with shared parity disk Independent Data disks with distributed parity blocks

" " "

Very high Read data transaction rate High aggregate Read transfer rate Low ratio of ECC (Parity) disks to data disks means high efficiency Highest Read data transaction rate Medium Write data transaction rate Best cost/performance for transactionoriented networks Supports multiple, simultaneous Read and Write Low ratio of ECC (Parity) disks to data disks means high efficiency
Doesnt support multiple, simultaneous Read and Write requests Transaction rate equal to that of a single disk drive at best (if spindles are synchronized) Worst Write transaction rate and Write aggregate transfer rate Write performance is slower than RAID 0 or RAID1

RAID 5

The features of RAID on this motherboard
This motherboard supports Striping (RAID 0), Mirroring (RAID 1), or Striping/Mirroring (RAID 0+1) operation. For the striping operation, the identical drives can read and write data in parallel to increase performance. The Mirroring operation creates a complete backup of your files. Striping with Mirroring operation offers both high read/write performance and fault tolerance although requiring 4 hard disks in order to do so.
2-1. Setting up RAID on this motherboard
Enter Advanced BIOS Features in the BIOS setup. Change the settings of First Boot Device, Second Boot Device and Third Boot Device to read ATA 100. See the figure below:
2-2. The BIOS setting menu
Reboot your system. Press <CTRL> and <H> key while booting up the system to enter the BIOS setting menu. The main menu of BIOS Setting Utility appears as shown below:
To select the option in the menu, you may: # Press F1 to view array status. 6 ABIT Computer Corporation
# Press (up, down arrow) to choose the option you want to confirm or to modify. # Press Enter to confirm the selection. # Press Esc to return to top menu. Create RAID This item allows you to create a RAID array. After you had selected the function you want in the main menus, you may press the <Enter> key to enter the sub menu as shown below:
Array Mode: This item allows you to select the appropriate RAID mode for the desired array. There are four modes to choose.
Striping (RAID 0): This item is recommended for high performance usage. Requires at least 2 disks. Mirror (RAID 1): This item is recommended for data security usage. Requires at least 2 disks. Striping and Mirror (RAID 0+1): This item is recommended for data security and high performance usage. Allows Mirroring with a Strip Array. Span (JBOD): This item is recommended for high capacity without redundancy or performance features usage. Requires at least 2 disks.

Select Disk Drives: This item allows you to select the disk drives to be used with the RAID array. Block Size: This item allows you to select the block size of the RAID array. There are five options: 4K, 8K, 16K, 32K, and 64K. Start Creation Process: After you have made your selection, choose this item and press <Enter> to start creation. HPT370 RAID Controller Guide 7
Delete RAID This item allows you to remove a RAID Array. Note: After you have made and confirmed this selection, all the data stored in the hard disk will be lost! Duplicate Mirror Disk This item allows you to select the disk you wish to duplicate in preparation for a Mirror Disk Array. After you have selected the function you want in the main menu, you may press the <Enter> key to enter the sub menu as shown below:
Select Source Disk: This item is to select the source disk. The size of source disk must be smaller or equal to the one of target disk. Select Target Disk: This item is to select the target disk. The size of target disk must be greater or equal to the one of source disk. Start Duplicating Process: After you had selected this item, the BIOS setting will take up to 30 minutes to run the duplication. Please wait or you may press <Esc> to cancel.
Create Spare Disk This item allows you to select the disk to be used as a spare for a Mirror Disk Array. Remove Spare Disk This item allows you to remove the spare disk from a Mirror Disk Array. Set Drive Mode This item allows you to select the drive transfer mode for the hard disk(s). Use the up/down arrow to select the menu option to Set Drive Mode and press <Enter>. In the Channel 8 ABIT Computer Corporation
Status, select the channel you would like to set and press <Enter>, there will comes out an asterisk mark in the parentheses indicating that the channel selection had be done. Choose the mode from the pop-up menu. You can choose from PIO 0 ~ 4, MW DMA 0 ~ 2, and UDMA 0 ~ 5.
Select Boot Disk This item allows you to select the boot disk among the hard disk(s).
Use the up/down arrow to select the menu option to Select Boot Disk and press <Enter>. In the Channel Status, select the channel you would like to set as bootable disk and press <Enter>, there will comes out an asterisk mark in the parentheses indicating that the channel selection had be done. HPT370 RAID Controller Guide 9

Software installation

Here we will show you the driver installation procedure under various operating systems.

3-1. DOS

This IDE RAID card BIOS supports DOS 5.x (or above) and Windows 3.1x without the software driver.

3-2. Windows 9x

Step 1: After the Windows 9x operating system had been installed and rebooted successfully, go to the Control Panel ! System Properties ! Device Manager. You can see the driver is not yet installed, and there is a device of ? PCI Mass Storage Controller under Other devices.

Step 2: Click right button of your mouse on the ? PCI Mass Storage Controller, and then go to Driver tab. Click Update Driver to go to next step.
Step 3: The wizard is going to install the PCI Mass Storage Controller. Click Next > to go to next step. 10 ABIT Computer Corporation
Step 7: Insert the driver disk and type the path in the text box a:\WIN (a:\ is your floppy drive letter), or E:\Drivers\hpt370\Win9x (E:\ is your CD-ROM drive letter). Step 4: Choose Display a list of all the drivers in a specific location and click Next > to go on. Click OK to go on.
Step 8: Choose HPT370 UDMA/ATA100 RAID Controller and click Next > to go on. Step 5: Choose SCSI controllers and click Next > to go on.
Step 9: Windows is now ready to install the driver. Click Next > to go on. Step 6: Click Have Disk to go on.
must be copied to the root directory of the diskette. Secondly, you have to set your system to Show all files. Otherwise you will be unable to copy some important system files to diskette.
Installing drivers during Windows NT installation:
If the NT 4.0 is first installed on the ATA100 drive, please follow the following installation procedure: Step 10: Windows has finished installing the driver. Click Finish to end the installation. Step 1: Set your system to boot from Drive A and then insert the Windows NT installation diskette 1/3. Power on your computer.
Step 2: The setup program will display a message about installing mass storage devices (see figure left) while you install NT4.0. Please press S to install the hpt370 driver Step 11: After rebooting the system, go to the Control Panel ! System Properties ! Device Manager. Now you can see the driver is installed under the item of SCSI controllers.

3-3. Windows NT 4.0

Before you start to install Windows NT 4.0, you have to create a driver disk for the Hot Rod 100 Pro. You can copy the Ultra ATA/100 driver files from the CD-Title that comes with this motherboard. The path for the Ultra DMA/100 driver files is E:\drivers\hpt370\winnt (E is your CD-ROM drive letter). Please note two things before you copy the driver files to diskette. Firstly, the driver files 12 ABIT Computer Corporation

Step 3: Select Other, requires disk provided by a hardware manufacturer, and then press <ENTER>.
Step 4: Insert the driver disk into drive A and press <ENTER>.
Step 7: After you configure your hard disk and specify the installation path, the NT setup will ask you to insert this HPT 370 IDE RAID controller driver disk into drive A again. Insert the driver disk, and then press <ENTER> to continue setup. If you have followed the steps described above, you should be finished installing your HPT 370 controller. For the rest of Windows NT installation steps, please follow the instructions displayed in the NT setup program.
Step 5: Use the UP or DOWN arrow key to move the highlight to the mass storage device you want and press <ENTER> to continue setup.
Installing drivers with existing Windows NT:
If there is an existing NT 4.0 file system, you can install the HPT 370 IDE RAID controller into the existing system by the following procedure:
Step 6: Windows NT setup has recognized this HPT 370 IDE RAID controller Press <ENTER> to continue setup.
Step 1: Go to Control Panel, and then enter SCSI Adapters.
Step 5: Click OK to go on. Step 2: Select Drivers, and then click Add.
Step 6: Insert the driver disk and type the path in the text box A:\nt (a:\ is your floppy drive letter), or E:\Drivers\hpt370\NT (E:\ is your CD-ROM drive letter). Step 3: Click Have Disk to go on.
Step 7: Click Yes to restart your computer.
Step 4: Insert this HPT 370 IDE RAID controller driver disk into drive A, and then click OK.

3-4. Windows 2000

If you want to install the Windows 2000 operating system on the hard drive utilizing the HPT 370 controller, please refer to the NT4.0 installation procedure. The following procedure is used only when you dont want to install the Windows 2000 operating system onto the hard drive utilizing the HPT 370 controller.
Step 1: Reboot the system. Windows will detect the new hardware automatically. Click Next> to go to the next step.
Step 4: Click Have Disk to go on.
Step 5: Insert the driver disk that comes with the Hot Rod 100 Pro and type the path in the text box A:\2K (a:\ is your floppy drive letter), or E:\Drivers\hpt370\2k (E:\ is your CD-ROM drive letter). Step 2: Choose Display a list of all the drivers in a specific location and click Next > to go on.

Step 6: Choose HPT370 UDMA/ATA100 RAID Controller and click Next > to go on.
Step 3: Choose SCSI and RAID controllers and click Next > to go on.
Step 10: Click Yes to restart the system.
Step 7: Windows is now ready to install the driver. Click Next > to go on.
Step 8: Click Yes > to go on.
Step 11: Go to the Control Panel ! System Properties ! Device Manager. Now you can see the driver is installed under the item of SCSI and RAID controllers.
Step 9: Windows has finished installing the driver. Click Finish to end the installation.