slow responding firewall server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



BTW have you seen this before:

http://www.iozone.org/

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?
>
>
>  
>


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux