Hi,
> I just checked with kernel 2.3.41, there is no explicit support for the
> i810 hard disk controller! What u must be using is the generic PCI
> chipset with DMA enabled. Correct me if i am wrong.
Well, I downloaded the latest 2.3.42 a couple of days ago, and
there is not much of a difference in seagate u8 situation. After my first
post to the list, I also got my vendor to provide me with another u8 (just
to make sure the first u8 is not a defective piece), and a samsung 8.4GB
(SV0842D). And the samsung works like a charm with *stock* RH6.1 kernel,
and with 2.2.14, and with 2.2.14 with patches and possibly with 2.3.42 (I
have yet to check that).
The samsung consistently cranks out 19-20MB/s. And I can see the
difference when I compile the kernel. With identical make menuconfigs, I
get the kernel compile done within 7 min on the u8, whereas with the
samsung its over within 5:30 min.
Funny thing is after applying hendrick's patches to 2.2.14, the u8
hdparm performance drops to 4MB/s, and the kernel compile also slows down
to about 8 min.
These kernel compile times are average of 2-3 runs. And the
timings were *very* consistent, barely deviating by a second or two.
> AFAIK, multiword DMA requires special kernel support. Using the generic
> PCI bus master drivers will be a bottle neck on the true performance of
By default, when you enable the dma flag, the drive normally boots
in best performance mode - that is what Mark Lord says in
Documentation/ide.txt.
He also says that due to udma, the ide disks "almost" are as fast
(when they are alone on the ide cable, i.e. no slaves) as scsi. Also
browsing through the code, you find places where they enable the udma
mode etc. And most importantly the ide.txt mentions that "NEW - Support
for BIOS configured udma transfers".
> Intel would have provided bus mastering drivers along with the
> motherboard which PCQ would have used to get the very best performance.
Quite possibe. But the fact remains is that linux does have
support for udma-33 (which is pretty old standard), and udma-33 is more
than enough to give you consistent throughput of about 20MB/s.
Even if you do the math (512 bytes/sec, 63 sectors per cylinder,
5400 rpm disk, track-track-seek 2-3 ms = about 25MB/s of maximum
throughput), u8 is capable of about 25 MB/s.
And the thing is I am able to get a respectable 20 MB/s on
samsung, with no changes in cabling/motherboard/kernel.
It was because of this that I wanted to know what is the
experience of others about this disk throughput thing.
> 1. IMHO, hdparm -t /dev/hd* alone is not last word in bench marking.
Ofcourse, but don't claim that kernel compilation is also not a
good benchmark. It is quite a disk intensive thing, and even though it
does tax your cpu/ram more than your disk, the disk has a bearing on the
results. It may not be a linear relation, but it does matter.
> 4. Do u seriously think that the Seagate U8 give a throughput of 24 Mega
> Bytes per sec? If it's true, then to read a file of 24 MB, it should
> take only *1* sec.Try reading a file of 24 MB under windows and time it!
I don't know how exactly pcq got their figures. But it does
indicate that the disk is capable of 24 MB/s and I am willing to trust
the pcq guys for that - especially when the math (mentioned above)
indicates that its possible. Now M$ may have a lot of crap filesystem
driver layers on top of that, but that's not the point. Its about the raw
disk subsystem performance.
> 6. Wherever possible, average transfer rates should be quoted as they
> indicate real world performance.
I don't know about PCQ, but in my case I have done both the hdparm
-t -T and kernel compilation at least a couple of dozen times, and the
results have been pretty consistent. The seagate gives max of 8 MB/s with
stock RH6.1, about 4-5 MB/s with 2.2.14+andre's patches and the samsung
consistently cranks out 18+ MB/s (mostly 19-20).
Anyway, my first post was just to gauge what is the situation in
general. The issue is that if the disk performance is so bad (only 1/4 to
1/5th of what's possible - however unstably - under M$), then its a cause
for concern.
Thanx a lot. But the trouble is I haven't heard from a single soul
on this list about their disk performance.
Regards,
Kedar.
--------------------------------------------------------------------------
LI is all for free speech, but this list was created for a purpose --
to help popularise Linux in India. If your messages are counterproductive
to that purpose, your privileges to submit messages can and will be revoked.
