On Mon, 9 Oct 2000, blizbor wrote:
> Andre, how are you benchmarking drives ?
Direct access below the driver without any file-system getting in the way.
No reorder of requests because of linear seeks.
These are kernel level tests because timers get set upon the execution of
the command block and terminate upon the interrupt regardless.
This is not for the faint of heart and the new method to pump/set the
request is now broken and I am try to fix it.
Cool tests like forced slip-rev seeks will return zone IO data.
They may be a way to test and create drive profiles that are stored and
reloaded to the kernel that will add the missing supercharge on Andrea's
elevator. Basically creating a physical LBA sector profile.
Trust that this will be painful to create because this is the secret of
the industry and I can not get access to it for Linux, even under
full-disclosure NDA's.
> Have you any idea did such results are really possible ?
> Could you sugest me better methods ?
Yes, but it will not be available until 2.5.
These will be PIO and DMA-PRD chains that will then allow for nibble level
verification of what the request sent and the stuff on the drive.
It may allow a forced-data recovery suite to be created for when you drive
craps out. This is because we will access the media directly and not
allow the kernel to get in the way of critical recoveries.
> Another question: looking through ide driver code I've found
> that there exists bad drive list with comment saying that
> it's updated when somebody emails bad words about drive.
> What you think about preparing test utility and let people
> around the world check and fill database of drives real "capabilities".
> This way list will be almost completed now, not after few years.
Can not do it until 2.5, without the UI/IOCTL needed one can never do what
you are asking for without completely writing an ata-bench-module and not
compile in the standard ATA/IDE driver.
The rewrite of 2.5 will be based on direct pass-through commands.
This will allow for 98%+ of the current IRQ disable/blocking to be
removed. Also the possible creation of table-io could return a
rocket-driver that is expected to give a 16-20X performance gain.
Currently with much of the IO setup being done with interrupts
block/masked/disable, we see a blanket system slowdown. Doing the
setup/command construction ahead of time allows for reduced total system
blocking.
If you have not guessed by now that drive-profile and table-io are
most-likely identical (caution still learning). You can see that I have a
wide margin to cover before I can hit limits that are not driver imposed.
This will be needed with the new SerialATA stuff, due to the single ended
nature of the beasties. I can only guess that IO will approach orders of
magnitude faster than what is known today. I can say no more than that it
will be fast.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:11 EST