Hi there,
In my experience with 20Gig drives of this age on a machine of this age,
20Megs/sec is about what I would expect....
25% drop is a lot, but its ok....
I know I can force the CHS in fdisk but I don't like doing that, it
seems that only some machines have the BIOS issue, putting them on the
same channel *always* fixes this issue.....
Since the transfer tate of the interface (i.e. cache test) is more than
10x the transfer rate of the disk, although not optimal by any stretch,
I don't really see a problem of having them on the same channel for this
application.
I should get the PIII board tomorrow, so I'll report back if it changes
anything!
whats the command line switch to do the sustained test for more than the
default number of seconds?
P.
Bryan J. Smith wrote:
>Peter Farrow <peter@xxxxxxxxxxx> wrote:
>
>
>>No,
>>hdparm -t gives you the uncached speed, -T gives you the
>>cached speed:
>>
>>
>
>You're right, I just looked at your numbers incorrectly. I
>was wondering how you got 62MB out of the Ultra33 interface,
>but didn't see it was for 3 seconds (doh!).
>
>
>
>>The disks are set the logical block assignments already,
>>and anaconda, detects the number of cylinders differently
>>
>>
>in
>
>
>>the install, which makes mirroring non symmetrical, trust
>>
>>
>me
>
>
>>when on channel 1 and 2, I've checked this in great detail,
>>
>>
>
>First off, if you use Anaconda with the master/slave on the
>primary, and the BIOS is LBA, then the partition table _will_
>be created with LBA. After that point, if you move the disk
>to the secondary channel, it _will_ continue to be LBA -- as
>Linux will read the geometry from the _disk_, not the BIOS.
>
>Secondly, you can _force_ different geometry by pulling up
>fdisk and entering "x". Then manually set the "h" (heads) to
>255, and the reduced "c" (cylinders) appropriately to match.
>Hit "r" to return to the main menu and "o" to install a new
>partition table.
>
>_Everyone_ needs to know how to do this -- especially when XP
>forces 255/63 in conflict with the BIOS on regular
>occassions. Ironically, this is no longer LBA48 compliant,
>and heads can exceed 255 now (don't get me started).
>
>
>
>>furthermore, simultaneous requests to both drives isn't
>>affecting performance as much as you imagine, here are the
>>results of a simultaneous hdparm test:
>> Timing buffered disk reads: Timing buffered disk reads:
>> 46 MB in 3.08 seconds = 14.93 MB/sec
>> 46 MB in 3.08 seconds = 14.92 MB/sec
>>
>>
>
>First off, that's a 25% drop right there!
>
>As I said, you're not only seeing a 50% drop because of the
>sharing, but additional overhead that could be up to 80%
>less. I'm sure if you make a sustained set of transfers, it
>would really kill it. The resetting of the ATA bus
>continually is part of the problem -- although you're using
>the same type of disk/mode, so at least it's not as bad as it
>could be.
>
>(E.g., putting a PIO CD-ROM on the same channel as a DMA hard
>drive typically results in far more than an 80% loss with all
>the reset overhead).
>
>Regardless, 15MBps is about 3-4x _slower_ than modern disks.
>
>
>
>>Also the old machine had them on the same channel two for
>>the same reason.....
>>This isn't the issue, its something else.......
>>
>>
>
>Oh, why didn't you mention the old config was the same?
>
>-- Bryan
>
>P.S. In a world with cheap, off-chipset Ultra33 cards
>(sub-$10 at many resellers) for additional channels (such as
>optical drives), why ever put two hard drives on the same
>channel?
>
>
>
>
