[WBEL-users] hdparm wbel 4.0respin1 and SATA

[Alon]

Hi All,

If I want to enable 32-bit and DMA on a SATA drive, is that something that can be done?

I tried to follow the instructions below,. but hit a wall with errors:

http://www.linuxdevcenter.com/pub/a/linux/2000/06/29/hdparm.html?page=2

Below is a copy from the article:
---------------------------



hdparm -c3 -m16 /dev/hda

/dev/hda:
 setting 32-bit I/O support flag to 3
 setting multcount to 16
 multcount    =  16 (on)
 I/O support  =  3 (32-bit w/sync)
Great! 32-bit sounds nice. And some multi-reads might work. Let's re-run the benchmark:

hdparm -tT /dev/hda


/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.41 seconds =90.78 MB/sec
 Timing buffered disk reads:  64 MB in  9.84 seconds = 6.50 MB/secWOW! Almost double the disk throughput without really trying! Incredible.

But wait, there's more: We're still not unmasking interrupts, using DMA, or even a using decent PIO mode! Of course, enabling these gets riskier. (Why is it always a trade-off between freedom and security?) The man page mentions trying Multiword DMA mode2, so:

hdparm -X34 -d1 -u1 /dev/hda...Unfortunately this seems to be unsupported on this particular box (it hung like an NT box running a Java app.) So, after rebooting it (again in single-user mode), I went with this:

hdparm -X66 -d1 -u1 -m16 -c3 /dev/hda

/dev/hda:
 setting 32-bit I/O support flag to 3
 setting multcount to 16
 setting unmaskirq to 1 (on)
 setting using_dma to 1 (on)
 setting xfermode to 66 (UltraDMA mode2)
 multcount    = 16 (on)
 I/O support  =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)And then checked:

hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.43 seconds =89.51 MB/sec
 Timing buffered disk reads:  64 MB in  3.18 seconds =20.13 MB/sec
20.13 MB/sec. A far cry from the miniscule 3.58 we started with...

By the way, notice how we specified the -m16 and -c3 switch again? That's because it doesn't remember your hdparm settings between reboots. Be sure to add the above line (not the test line with -tT flags!) to your /etc/rc.d/* scripts once you're sure the system is stable (and preferably after your fsck runs; having an extensive fs check run with your controller in a flaky mode may be a good way to generate vast quantities of entropy, but it's no way to administer a system. At least not with a straight face...)

Now, after running the benchmark a few more times, reboot in multi-user mode and fire up X. Load Netscape. And try not to fall out of your chair.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://beau.org/pipermail/whitebox-users/attachments/20060512/a8aa9a4b/attachment.htm