LinuxQuestions.org - How to boot RO && Single User Mode to test hdparm ???

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - How to boot RO && Single User Mode to test hdparm ??? (https://www.linuxquestions.org/questions/slackware-14/how-to-boot-ro-and-and-single-user-mode-to-test-hdparm-334247/)

How to boot RO && Single User Mode to test hdparm ???

I was checking some websites yesterday and read that playing around with hdparm could really boost your system :)

My questions is how to boot in Read-Only(i use lilo) and Single user mode so that you can do some tests before running hdparm permanltly(rc.local) because you might damage the filesystem !!!

i use slack 10.1 and kernel 2.6.11.12
a lot of people don't mind to use hdparm to boost up but i believe it's a nice tweak for linux :)

It'll be remounted read-write by the kernel before you get to the runlevel.

that said, booting read-write won't cause a problem. The only hdparm that'll really improve your performance noticably is DMA, and you can check that in any runlevel. Usually, it'll be enabled by default as long as the kernel supports it. If you really want to boot single user mode, at the LILO prompt type "{imagename} 1". That'll kick you to runlevel 1, or single user mode. (and yes, my signature is similar in nature ;))

Here's what mine looks like:

Code:

root@whiterabbit:~# hdparm /dev/hde



/dev/hde:

 multcount    = 16 (on)

 IO_support  =  0 (default 16-bit)

 unmaskirq    =  0 (off)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly    =  0 (off)

 readahead    = 256 (on)

 geometry    = 65535/16/63, sectors = 80054059008, start = 0

Now, I could also improve throughput by using 32-bit mode, but I'm lazy and that would require a kernel recompile. Also, the improvement wouldn't be that great. Certainly not as great as the hit I'd take by disabling DMA.

If you need to enable DMA (Direct Memory Access), you will need to compile the right IDE/SATA driver into your kernel. If you know the chipset by heart, great. On my system, /dev/hde is primary master on a HighPoint HPT372 RAID controller, for example. The other IDE controller in my system is a VIA 82C. You can tell by checking the output of lspci:

Code:

root@whiterabbit:~# lspci

00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]

00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP]

00:08.0 Multimedia audio controller: Creative Labs: Unknown device 0007

00:0b.0 Network controller: Harris Semiconductor Prism 2.5 Wavelan chipset (rev 01)

00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge

00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06)

00:11.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 1b)

00:11.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 1b)

00:11.4 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 1b)

00:13.0 RAID bus controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 05)

01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 4153

01:00.1 Display controller: ATI Technologies Inc: Unknown device 4173

Once you know which chipset to include, I'd suggest including the driver directly in the kernel. That'll speed up boot time, because the kernel will be able to use DMA from the start, rather than having to wait until the module is loaded. While you're there, you might as well enable 32-bit IDE access if your controller supports it. Anything else in hdparm probably won't result in a noticable improvement in performance.

EDIT: and just so you know what it looks like, here's the hdparm from my server:

Code:

root@alice:~# hdparm /dev/hda



/dev/hda:

 multcount    = 16 (on)

 IO_support  =  1 (32-bit)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly    =  0 (off)

 readahead    = 256 (on)

 geometry    = 24704/16/63, sectors = 12749635584, start = 0

/dev/hdc has the same hdparms, but different geometry. It's 10 times the size of the system/swap drive. :) I did not need to set any of those options manually. I just included the right IDE driver in the kernel at compile time, and the kernel automatically detects the correct settings.

tnx for the information killerbob :)

i have an old 20GB 5400rpm 2mb-buffer Western Digital disk and i have the IDE driver compiled in the kernel.

"hdparm -c3 -m16 /dev/hda" is what i have in my rc.local
It gives me a little better thoughput than "hdparm -X66 -d1 -u1 -m16 -c3 /dev/hda" (which enables DMA)!!!

But it is still 5.28MB/s i think..kinda not much though :)
5.28 is the second value when i run the "hdparm -tT /dev/hda" test..
The first value i get is about 200MB/s

Remember that you won't *ever* see more than about 13mbyte/s on an IDE channel. That's the maximum burst speed for IDE. You'd have to switch to ATA, SCSI, or SATA to see any improvement over it. 5mb/s sustained is not bad for IDE.

You should check what's actually set with hdparm once you're up, though. You could find that DMA is already enabled. The kernel will enable DMA access if it can.

Quote:

Originally posted by killerbob
Remember that you won't *ever* see more than about 13mbyte/s on an IDE channel. That's the maximum burst speed for IDE. You'd have to switch to ATA, SCSI, or SATA to see any improvement over it. 5mb/s sustained is not bad for IDE.

You should check what's actually set with hdparm once you're up, though. You could find that DMA is already enabled. The kernel will enable DMA access if it can.

Nothing is enabled by default.Kernel cannot enable DMA.
I'll give it a closer look when i get back home and post the info :)

killerbob, do you know why multcount feature is considered as dangerous ?
[edit]
forget it... I found the answer in the man page for hdparm ;)