Contrary to what you might think this chipset was not fully supported until recently, when code submitted by Vojtech Pavlik was incorporated into the 2.4.19-pre9.patch . None of the kernels that you can emerge through portage have that patch, so if you want full support for that chipset you have to build your own patched kernel. Keep in mind that this patch is a work in progress.

So what you need to do is emerge vanilla sources, then head over to ftp.kernel.org get 2.4.19-pre9.patch and apply that patch to the vanilla sources.

Optionally you can also get the pre-emptive kernel patch and apply that AFTER you applied the patch mentioned above.

I did this and my system (Soyo Dragon +, kt266a/VT8233CE) runs smoother than ever:)

Both of those above are an average of about 4 tests on both hard drives.... none of them were off more then 1 MB/sec between every other one.

Question:
What's my bottlekneck that's causeing the Timing buffer-cache read to top out at 160 MB/sec? I've been people with over 200. This ATA/100 UDMA5 on 2 7200RPM Maxtor 60GB HD's w/ 2MB Cache.

Another question that's kinda scary:
I booted into single user mode to try this the first time, and when I rebooted back into normal mode, none of the settings were saved. In fact, I noticed that every time I changed it, it wouldn't be saved after a reboot. So I just aded the command to my /etc/conf.d/local.start file and it works fine now. BUT, one major thing... when I set it to UDMA, even though my mobo is suppost to support it, I get the following error in /var/log/messages:

I got to reading about it on Google, and I found that UDMA has been disabled in my IDE chipset b/c it's not stable? How can I get around this, and what would happen if I forced it to run at UDMA5 all the time, which I can do with the local.start script.

Is there somewhere I can put the same thing that's in my local.start script to get hdparm to change the HD mode before everything starts loading so my system will boot up faster?

Don't get all caught up in the numbers here. The point of this all isn't to get
the highest numbers you can, its really to get the the controller and chipset
set up to transfer data as fast as the drive can. As soon as you get the
controller set up to run as fast as the drive can, you will not see any more
significant performance increases. I have an old 7200 rpm udma 66 drive
that will only transfer data at 16 mb's a sec when configured correctly. Its
that the drive was one of the first to come out at that speed, and thats as
fast as the heads can read the data from the platters. I have a new one
thats udma 133 that reads at 46 mb's a sec.
You ought to test your computer at these different settings by running
something like
time dd if=/dev/zero of=1000mbfile bs=1000k count=1000
That will time your machine writing a 1 gig file. Be sure to delete it.
thats one way you can see the real performance differences.
By the way, I've found that dd transfers much faster with the larger
block sizes, so i changed the defaults in the code on my machine and
recompiled it. Call me crazy.

hey, this is quite good :)
you might want udma6, though I dont know if you will actually notice any difference...

btw, I see everyone here is using -m 16 ...
Always been using -m 32 (yes my disks do suppor that :)

btw, a quote from the hdparm manual :

Quote:

Western Digital recommends lower settings of 4 to 8 on many of their drives, due tiny (32kB) drive buffers and non-optimized buffering algorithms.
The -i flag can be used to find the maximum setting supported by an installed drive (look for MaxMultSect in the output).

this is probably not true any more with modern disks, but you never know :)_________________mat

When I read this thread, that isn't a very bad performance, but I wonder if it would be any better if I was able to set -X 68.

Could the CDRom drive (also on ide0) prevent this?

On ide1 there's a cd burner (hp9100+), so I think that is why they put (didn't built this machine myself) on ide0.

Someone an idea on how to force udma4 performance?

Ruud

[EDIT]
so oke i was a bit hasty with the keyboard. Turns out I didn't have VIA support compiled in the kernel. Did that and now -X68 doesn't give the error/warning. However, performance hasn't improved a bit[/EDIT]

Sp4rky, you were lucky you didn't have faster drives. The reason for the limitation, and kernel option, is that a lot of machines with buggy Via chipsets can have "massive file corruption" if UDMA modes > 2 (33MB/s) are enabled.

I found out the hard way over a year ago. Everything tested good until I transferred over 100 MB. at once at >32 MB/s. UDMA 2 can never sustain this rate. It is barely possible with UDMA 4, fairly common with UDMA 5. I did a good bit of testing settings before I used them for real work.

Until I had a disk where data came off the head fast enough to sustain that rate it wasn't even possible. (Forget the big numbers on the outside of the box.) If I hadn't had >100 MB. of RAM there wouldn't have been such a transfer anyway. Other people had no trouble until they installed a new sound card. It isn't worthwhile to find out what you can get away with.

Gentoo kernels have the Via option set by default. People, don't turn it off if you ever plan to run it on a machine with a Via 686a or 686b chip. (Some may still be sold AFAIK. ) The easy option for software is to permanently limit performance. Gentoo is different.

Don't forget that buffer-cache reads only use memory access (no access to the disk)

from man hdparm

Code:

-T Perform timings of cache reads for benchmark and comparison pur-
poses. For meaningful results, this operation should be repeated
2-3 times on an otherwise inactive system (no other active pro-
cesses) with at least a couple of megabytes of free memory. This
displays the speed of reading directly from the Linux buffer cache
without disk access. This measurement is essentially an indica-
tion of the throughput of the processor, cache, and memory of the
system under test. If the -t flag is also specified, then a cor-
rection factor based on the outcome of -T will be incorporated
into the result reported for the -t operation.

BTW, you should run benchmarks more than one time to get relevant results. I would say at least 7 times (I would be more confortable with 20), but I'm not taking in account statisc rules -- just magic numbers.

squanto wrote:

Bloody Bastard: thank you for enlightening me. I did not know that. Now it makes sense that my 2 drives would have similar ratings for buffered cache reads.

Andrew

Can anyone beat my 45.98MB / sec? just curious. I run ReiserFS with notail on my WD special edition, on Epox 8KHA+ board.

BTW, you should run benchmarks more than one time to get relevant results. I would say at least 7 times (I would be more confortable with 20), but I'm not taking in account statisc rules -- just magic numbers.

I ran it 8 times, and they were all within 1MB/sec of that number, but I can post all if you want , but anyways, not that it is a competition, I am just happy that my $107 didn't go to waste, but actually got me a high proformance drive for once.
Now if only I could afford an opteron.... :drool: :drool:

I compiled the 2.4.19 kernel with support for the Intel Piix driver. And the 3ware card is on a 266MB max speed (64bitx33mhz). Could it be that there some switch to turn it from 32bit to 64bit ? so in fact its using 32bit mode now?

Anyway over to the portable. I was very dissapointet with the speed here. Its a 1.7ghz P4 with a 5400rpm toshiba drive. I hoped to get more than this:

Anyone have any idea what i should do to add DMA support to the kernel for both machines? Even on the portable it locks up when i try to send much data on the pure-ftpd thats running on it. Well it doesnt lockup but it sorta stops for a few seq's even if TOP says pureftp uses 25% cpu and not 100%