Impact of DMA Inclusion in SkyOS Build 6356 Examined
Direct Memory Access, hereafter referred to as DMA, is an essential feature of computers and operating systems. It allows data transfer to be made between devices without the interaction of the CPU, therefore freeing it to do other tasks.
On October 15, Robert Szeleney released SkyOS build 6356 for testing to the alpha team. The changelog sparked my interest when I read that the new ATA driver using UDMA5 boosted data transfer rates from 2.6MB/s to 38MB/s. One of the most common complaints about SkyOS has been the time of installation. It has been painfully slow ever since I've tested it, and it was only more painfully obvious when more packages were added to the default installation.
We set out to determine how much of a difference DMA made on (1) the installation time, (2) speed of indexing, (3) program loading time, and (4) general hard disk performance. Our prediction was that DMA support would greatly speed up the installation, and marginally impact general usage.
Hoping and praying that the installation time had been shortened, we set out to benchmark 6356 with 6179, the most recent build prior to 6356.
Our test system's specifications were:
- AMD Athlon 2100+ Thoroughbred @ 266MHz FSB
- 1 GB RAM
- Chaintech 7NIL1
- Radeon 8500
- Maxtor 120GB 8MB cache 7200 RPM
Installation was a breeze with 6356. Whereas older builds of SkyOS had taken up to an hour to fully install, 6356 was done after 14:05. To compare, 6179 was busy installing Berkeley DB at the 14:05 mark. For reference, SkyOS installs base.pkg and unix.pkg first and then follows by installing the rest in alphabetical order. Berkeley DB's package begins with a 'd'.
Our success with installing 6179 was extremely limited. Twice did we experience processor exceptions after twenty minutes, and once were we kindly shown the kernel debugger after installing for fifty-two minutes.
Cutting the installation time from an hour to under fifteen minutes is certainly a great accomplishment, but what affect does DMA have on normal usage?
Upon booting SkyOS for the first time, we were greeted with a screen asking to index our SkyFS formatted hard disk. The indexer was able to complete its operation in 7:55 after indexing 1634 files, 67545 words, and checked 20329 total files. Since we were not able to install all the packages from the previous build, our indexing benchmark is not on an even playing field. We were able to index 654 files, 9172 words, and check 4469 total files in 1:57 for some comparison though.
Next we tested program loading times. More specifically, we tested the loading times of Firefox. As most SkyOS followers know, Firefox can be a pain. Its first time starting is much longer than subsequent loading times. In 6356, Firefox took 23 seconds to open the first time but only took 5 seconds to load a second time. Our semi-broken 6179 installation wouldn't even open Firefox.
Lastly, we tested hard drive performance by copying, compressing, and decompressing the Firefox installation. Our results were as shown.
|Test||Build 6356||Build 6179|
|tar/bz2 compression||25 seconds||34 seconds|
|tar/bz2 decompression (7.78MB)||32 seconds||35 seconds|
|tar/gz compression||18 seconds||34 seconds|
|tar/gz decompression (8.50MB)||30 seconds||36 seconds|
|directory copy||37 seconds||37 seconds|
We received some baffling results when we realized that compression times in both cases were shorter than decompression times. This would lead us to believe that the CPU is not the bottleneck but rather still hard drive performance. Hopefully this means there is still more performance yet to be squeezed out of the ATA driver.
To conclude, it seems we were correct in our hypothesis that DMA would speed up the installation time. It certainly did, by more than 45 minutes we'd guess. If it wasn't for our bad luck, or rather 6179's instability, we would have more conclusive results concerning performance improvements in general usage.
If the idea of an hour or more installation time has scared you away from testing out SkyOS it seems like this would be a good time to start, or return to, testing. Maybe it was lack of USB support or printing? Again, now is a good time to test.
If you see any type of error in this article (grammatical, spelling, incorrect information, HTML validator errors) report them to me.
Article and testing by Matt Turner and Cameron Bunce.
October 15, 2006.