ATA Device Advances
Date 2004/7/11 18:37:52 | Topic: AROS
| Michael Schulz have just commited his recent changes to ata.device. As promised, this update includes basic UDMA support together with some fixes (LBA48 harddrives work now as expected, and the drive capacities up to 2^57 bytes are supported).
!!WARNING!!
Because he still haven't added specific chipset support, the UDMA support is disabled by default. One can turn it on with forcedma parameter for ata.device. Eg. If you want to have both 32-bit IO and (where supported by drive) UDMA support, add the following parameter to GRUB:
ATA=32bit,forcedma
But wait! The generic DMA support bases on the BIOS setup. So be extremely carefull. On his machine for example BIOS sets chipset timing properly up, as well as drive UDMA setup. But it doesn't have to be so on every single machine. It may happen, that some nasty BIOS will do something badly, and then either UDMA will not work at all, or it may become a bit destructive to the contents of your harddrive.
You have been warned! :)
Now, the UDMA mode works impressively. When chooing AROS from the GRUB menu, and pressing Enter, it takes approximatelly 9 secods to fully boot into aros (I
start Opaque and ClickToFront commodities in S:User-startup additionally). It needs that "much" because the kernel itself needs 8 seconds. If the kernel could be a bit faster with boot, we could reach even faster bootups.
The affs works slightly better with UDMA active, however it's still not optimal. Reading is quick, but writes are still very painful. During debug of ata.device Michael noticed that affs reads *everything* sector after sector. Moreover, the output from ata.device suggested, that it reads the bitmap and root block all the time, instead of having it cached. Well, as already mentioned by Sebastian on the AROS Dev ML, it is a research-filesystem written by him from scratch. There are many places for possible optimisations though.
Talking about numbers. Michael used some 5-years old 30GB Seagate harddrive for testing and created a 500MB aros partition on it. The results for both PIO and UDMA modes can be found under:
http://home.tu-clausthal.de/~misc/scsispeed-dma.txt
http://home.tu-clausthal.de/~misc/scsispeed-nodma.txt
Small comments for those, who are not willing to look into these files:
Raw linear read from ata.device using highest PIO mode available, results in approx. 6900KB/s in the best case (256KB readed with one DoIO), and 3000KB/s in the worst case (512 bytes readed with one DoIO). So nothing really changed since last time. In case of UDMA mode, the best transfer is approx. 40100KB/s, whereas the worst transfer is 4300KB/s. As you can see, DMA profits from huge blocks transferred. Please note, that using the LBA28 addressing, DMA is capable to transfer 128KB at once, whereas in the LBA48 mode it can transfer up to 32MB in one block.
The affs test (diskspeed files) shows the weakness of afs.handler in full beauty. The basic file operations gain a bit from UDMA mode (eg. directory scan changes from 6800 files/s up to 8900 files/s. As to the basic operations
on file, only reading from files gets the speed boost (from 3MB/s up to approx. 6MB/s - note the 40MB/s transfer capability of this harddrive!), whereas the file write and file creation do not change at all.
As a closing have fun testing the improved ATA Device :).
|
|