Bought 1 Gbyte of compact flash, and an CF-IDE converter. The CF will be used as the boot and root drive in a carputer (instead of the 2.5" currently). CF has a limited number of erase/write cycles, so writes are cached to ram disk using the copy-on-write loopback driver (cowloop hompage). With the cow, the CF can be updated only when rebooting/shutting down, or just not updated at all.
Being solid state, the random seek time should be very low, much lower than 2.5" or 3.5" hard disks. This short note shows a quick comparison using IOTest by Solid Data Systems (one of the few that would do read only tests on unformatted HDs). The code had also been changed to allow for flushing buffers between each block size test.
The Compact Flash (Kingston, 24x) was tested in an Intel socket 370 board with a Celeron 500, 256 meg of ram, using Debian 3.1 and a 2.6.8 kernel.
The same Compact Flash was also tested in an VIA Socket A board with a XP2000+, 512 meg of ram, using RedHat 7.3 and a 2.4.27 kernel. This is a good comparison because 1) The XP2000+ is a much faster processor that removes any limit the CPU power would have placed on the benchmark. Compact Flash uses PIO transfer modes and so needs more CPU power than DMA modes and 2) the quality of the drivers for your chipset, as this test clearly shows the Intel board with the lesser processor is faster with small block reads.
The 3.5" IDE 7200 rpm HD (Maxtor, model 6Y080L0) was an 80 gig model, but the benchmark used only a 1 Gbyte partition near the start of the drive. This drive was in an Nvidia based board with an XP2800+ Athlon, 1 gig of ram, using RedHat 7.3 and a 2.4.29 kernel.
The 3.5" SCSI 10,000 rpm HD (IBM, model DDYS-T18350N) was an 18 gig model, with IOtest altered to use the first 1 gigabyte. This was in a DEC (HP, Compac, etc.) Alpha EV68 833MHz, with 1 gig of ram.
The 3.5" SATA 10,000 rpm HD (WD, Raptor) was 76 gig, with IOtest altered to use only the first 1 gigabyte. This was tested on an Nvidea based board with an Athlon 2800+, 1 gig of ram, using Debian 3.1 and a 2.6.13 kernel.
Look at the html source if you want the raw data.
Data Rates:
Seek Time (estimated from IOs/second, so the smallest blocksize of 512 bytes is most accurate):
Looking at the numbers, CF is 8.3 times faster than the IDE drive when the block size is small, even when the block size is 4K the CF is still 4.7 times faster. But, the CF is using a PIO transfer mode, and this really starts to show as the blocks get larger and the Maxtor spends less time seeking and more time transfering data. The SCSI drive is more like the IDE, but slightly faster in every way. So the CF will always be limited by PIO, but will generally be faster than the 3.5" for small IO operations like those during boot up. Of course, the CF is much more expensive and so you could buy much more storage that is nearly as fast to much faster, and doesn't have a relatively limited number of write operations. The only real advantage then is durability, and the fast seek time is a bonus.
Another interesting observation comes from the CF in both the Celeron 500 and XP2000+ systems. As can be seen, the plot lines cross. With small block sizes the VIA based XP2000+ just can't shift as many bytes as the Intel based Celeron 500. It could be argued this is because the C500 was running a 2.6.x kernel, whereas the XP2000+ was running a 2.4.x kernel. This would need further testing. Either way, you can see that for bigger block sizes the added cpu power of the XP2000+ starts to play its part. The C500 runs out of steam and the curve flattens, but the XP2000+ does manange an increase for longer and never flattens out.
1. On both the C500 and the XP2000+ machines, hdparm -c1 (enable 32bit transfers) improved Compact Flash throughput by 70% for all tests. Changing the PIO mode or unmaskirq made no difference.
2. According to hdparm, the sequential read rate is 9.2megbytes per second on the Celeron 500 with Intel motherboard running a 2.6.x kernel.
3. As shown in the graphs, a faster machine does not necessarly lead to a faster result across the board. The data passes through a multitude of layers in the OS and hardware, and any one of them could be a problem with your motherboard/CPU/drive.
Written by Greg: greg at csc liv ac uk, on 14/8/05. Would welcome any comments.