Re: [gentoo-user] SATA tuning ?

Re: [gentoo-user] SATA tuning ?

[Richard Fish]

On 8/15/06, Meino Christian Cramer <Meino.Cramer@gmx.de> wrote:
> Hi,
>
>  since SATA does not support DMA I would be interested in other ways
>  to tune the SATA interface.

Huh?  SATA _does_ support DMA, and it is always enabled.

>  Does someone knows some working things to do for tuning the SATA
>  interface?

If you have chosen the correct driver in the your kernel
configuration, it is self-tuning.  There is no more performance to be
had generally.

What problem are you trying to solve?  What does "hdparm -Tt /dev/sda"
actually report?

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] SATA tuning ?

[Meino Christian Cramer]

From: "Richard Fish" <bigfish@asmallpond.org>
Subject: Re: [gentoo-user] SATA tuning ?
Date: Tue, 15 Aug 2006 10:32:17 -0700

Hi Richard,
 
 thank you for answering ! :)

> On 8/15/06, Meino Christian Cramer <Meino.Cramer@gmx.de> wrote:
> > Hi,
> >
> >  since SATA does not support DMA I would be interested in other ways
> >  to tune the SATA interface.
> 
> Huh?  SATA _does_ support DMA, and it is always enabled.
> 
> >  Does someone knows some working things to do for tuning the SATA
> >  interface?
> 
> If you have chosen the correct driver in the your kernel
> configuration, it is self-tuning.  There is no more performance to be
> had generally.
> 
> What problem are you trying to solve?  What does "hdparm -Tt /dev/sda"
> actually report?

 I used the following:

    #
    # Please see Documentation/ide.txt for help/info on IDE drives
    #
    # CONFIG_BLK_DEV_IDE_SATA is not set
    ...
    #
    # SCSI low-level drivers
    #
    ...
    CONFIG_SCSI_SATA=y
    ...
    CONFIG_SCSI_SATA_VIA=y
    
    (scsi support is enabled also)

 Just as an info: lspci say:

   00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
   00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
   00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
   00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
   00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
   00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
   00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
   00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
   00:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
   00:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
   00:0c.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus DVD Decoder (rev 02)
   00:0d.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 03)
   00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
   00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
   00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
   00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
   00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
   00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
   00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
   00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
   00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
   00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 80)
   00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
   00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
   00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
   00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
   01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500]

 hdparm reports on a system, where no other task is running:

    solfire:Mail/vim>sudo hdparm -tT /dev/sda
    /dev/sda:
    Timing cached reads:   2996 MB in  2.00 seconds = 1499.13 MB/sec
    Timing buffered disk reads:  174 MB in  3.01 seconds =  57.79 MB/sec

 which is slightly faster then my previous PATA setup.

 BUT

 WHen doing things, which mixes higher CPU-loads with  massive hd
 utilization, things are going slow (compilation of Blender for
 example).

 It /seems/, that SATA uses more of the CPU capacity than PATA.
 I read the information about "SATA not DMA capable" in the Net. As I
 said: Partly contradictionary....

 And it seems that DMA is only possible with NCQ enabled, which is
 currently (linux 2.6.17.8, vanilla) not the case with the kernel.

 But as said before: This infos are all of "copy and paste" nature...I
 have no way to proof them!!! Thats why I post my question...

> -Richard
> -- 
> gentoo-user@gentoo.org mailing list
> 

Keep hacking!
Meino
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] SATA tuning ?

[Richard Fish]

Moving this back to gentoo-user, as I accidentally replied off list.

Meino, please don't CC me directly on replies.  I'll read them on the list...

On 8/15/06, Meino Christian Cramer <Meino.Cramer@gmx.de> wrote:
> > >  WHen doing things, which mixes higher CPU-loads with  massive hd
> > >  utilization, things are going slow (compilation of Blender for
> > >  example).
> >
> > Ok, let's try to test that.  We'll start by saturating your CPU(s).
> > On one terminal start "bzip2 -9 < /dev/urandom >/dev/null".
>
>   This commandline puts a BIG SMILE onto my face ! Yes, this is as
>   simple as it is genious!!! Great! Really a nice CPU barbeque !
>
> > (If you
> > have multiple processors, start one of these bzip2 commands on one
> > terminal for each processor you have).
> >
> > Then on another, repeat the "hdparm -Tt /dev/sda"
>
>   These are the results __without__ the CPU roaster:
>
>     solfire:Mail/vim>sudo hdparm -tT /dev/sda
>     /dev/sda:
>     Timing cached reads:   2996 MB in  2.00 seconds = 1499.13 MB/sec
>     Timing buffered disk reads:  174 MB in  3.01 seconds =  57.79 MB/sec
>
>   and this are the results __with__ the CPU roaster:
>
> solfire:/home/mccramer>sudo hdparm -Tt /dev/sda
>     solfire:/home/mccramer>sudo hdparm -Tt /dev/sda
>     /dev/sda:
>     Timing cached reads:   2160 MB in  2.10 seconds = 1030.12 MB/sec
>     Timing buffered disk reads:  174 MB in  3.03 seconds =  57.41 MB/sec
>
>
> The chached reads dropped by ~469MByte/s. The buffered reads are
> nearly the same.

The buffered reads are all we care about.  They are the actual reads
from the disk to RAM.  The cached reads is just a repeated read of the
same sector of the disk, so today is really just a test of your memory
bandwidth.  Since we are loading memory and the CPU pretty heavily for
this test, and significant drop is to be expected.

So, it is not CPU utilization that is hurting your performance.

You mentioned problems compiling.  The most likely case I can think of
is that you do not have enough memory, and are inducing the system to
swap.  Indeed when compiling most programs, you should see very little
if any disk activity.  This is particularly suspect if you have
something like MAKEOPTS=-j4.

Regards,
-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] SATA tuning ?

[Meino Christian Cramer]

From: "Richard Fish" <bigfish@asmallpond.org>
Subject: Re: [gentoo-user] SATA tuning ?
Date: Tue, 15 Aug 2006 21:47:20 -0700

> Moving this back to gentoo-user, as I accidentally replied off list.
> 
> Meino, please don't CC me directly on replies.  I'll read them on the list...

  ...sorry...my fault...bu the previous mail was a private one to me...

> On 8/15/06, Meino Christian Cramer <Meino.Cramer@gmx.de> wrote:
> > > >  WHen doing things, which mixes higher CPU-loads with  massive hd
> > > >  utilization, things are going slow (compilation of Blender for
> > > >  example).
> > >
> > > Ok, let's try to test that.  We'll start by saturating your CPU(s).
> > > On one terminal start "bzip2 -9 < /dev/urandom >/dev/null".
> >
> >   This commandline puts a BIG SMILE onto my face ! Yes, this is as
> >   simple as it is genious!!! Great! Really a nice CPU barbeque !
> >
> > > (If you
> > > have multiple processors, start one of these bzip2 commands on one
> > > terminal for each processor you have).
> > >
> > > Then on another, repeat the "hdparm -Tt /dev/sda"
> >
> >   These are the results __without__ the CPU roaster:
> >
> >     solfire:Mail/vim>sudo hdparm -tT /dev/sda
> >     /dev/sda:
> >     Timing cached reads:   2996 MB in  2.00 seconds = 1499.13 MB/sec
> >     Timing buffered disk reads:  174 MB in  3.01 seconds =  57.79 MB/sec
> >
> >   and this are the results __with__ the CPU roaster:
> >
> > solfire:/home/mccramer>sudo hdparm -Tt /dev/sda
> >     solfire:/home/mccramer>sudo hdparm -Tt /dev/sda
> >     /dev/sda:
> >     Timing cached reads:   2160 MB in  2.10 seconds = 1030.12 MB/sec
> >     Timing buffered disk reads:  174 MB in  3.03 seconds =  57.41 MB/sec
> >
> >
> > The chached reads dropped by ~469MByte/s. The buffered reads are
> > nearly the same.
> 
> The buffered reads are all we care about.  They are the actual reads
> from the disk to RAM.  The cached reads is just a repeated read of the
> same sector of the disk, so today is really just a test of your memory
> bandwidth.  Since we are loading memory and the CPU pretty heavily for
> this test, and significant drop is to be expected.

  Ok...sounds good -- in the sense of: It seems, that I have no
  hardware problem anywhere in my Linux box...
 
> So, it is not CPU utilization that is hurting your performance.

  ( :) imaging the above sentence *WITHOUT* the current context :) )

  This is the eigth wonder of the world...the first time when CPU load
  does *not* hurt system performance! Oh yeah! I will send all my
  render tasks to the...floppy controller, hahahahahahaa :))))))

  (sorry could not resist...I am a little daft this morning as it seems :O))
 
> You mentioned problems compiling.  The most likely case I can think of
> is that you do not have enough memory, and are inducing the system to
> swap.  

  Hmmm...1GByte Dualchannel-RAM should be enough for compiling Blender
  (for example).

> Indeed when compiling most programs, you should see very little
> if any disk activity.  

  My SATA disk (Seagate ST3200827AS) is heavily shakeing its head when
  compiling...

> This is particularly suspect if you have
> something like MAKEOPTS=-j4.

  Yes, normally I use "make -j 4" for useing both cores.

  May be I foolishly forget something to switch on or off in my BIOS
  while migrating from PATA to SATA ? The only PATAs in my system is a
  Plextor CD reader/burner and a LG DVD reader/burner on IDE1
  (scnd. channel).

  My mobo is a ASUS AV8 with AMI BIOS (upgraded to the "newest"
  version I could find on the net).

> Regards,
> -Richard
> -- 
> gentoo-user@gentoo.org mailing list
> 
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] SATA tuning ?

[Andrew Frink]

[-- Attachment #1: Type: text/plain, Size: 4015 bytes --]

Meino,
it wouldn't hurt to know which filesystem you are using, as that
could(unlikely) be the problem

Cynyr

On 8/16/06, Meino Christian Cramer <Meino.Cramer@gmx.de> wrote:
>
> From: "Richard Fish" <bigfish@asmallpond.org>
> Subject: Re: [gentoo-user] SATA tuning ?
> Date: Tue, 15 Aug 2006 21:47:20 -0700
>
> > Moving this back to gentoo-user, as I accidentally replied off list.
> >
> > Meino, please don't CC me directly on replies.  I'll read them on the
> list...
>
>   ...sorry...my fault...bu the previous mail was a private one to me...
>
> > On 8/15/06, Meino Christian Cramer <Meino.Cramer@gmx.de> wrote:
> > > > >  WHen doing things, which mixes higher CPU-loads with  massive hd
> > > > >  utilization, things are going slow (compilation of Blender for
> > > > >  example).
> > > >
> > > > Ok, let's try to test that.  We'll start by saturating your CPU(s).
> > > > On one terminal start "bzip2 -9 < /dev/urandom >/dev/null".
> > >
> > >   This commandline puts a BIG SMILE onto my face ! Yes, this is as
> > >   simple as it is genious!!! Great! Really a nice CPU barbeque !
> > >
> > > > (If you
> > > > have multiple processors, start one of these bzip2 commands on one
> > > > terminal for each processor you have).
> > > >
> > > > Then on another, repeat the "hdparm -Tt /dev/sda"
> > >
> > >   These are the results __without__ the CPU roaster:
> > >
> > >     solfire:Mail/vim>sudo hdparm -tT /dev/sda
> > >     /dev/sda:
> > >     Timing cached reads:   2996 MB in  2.00 seconds = 1499.13 MB/sec
> > >     Timing buffered disk reads:  174 MB in  3.01 seconds =  57.79MB/sec
> > >
> > >   and this are the results __with__ the CPU roaster:
> > >
> > > solfire:/home/mccramer>sudo hdparm -Tt /dev/sda
> > >     solfire:/home/mccramer>sudo hdparm -Tt /dev/sda
> > >     /dev/sda:
> > >     Timing cached reads:   2160 MB in  2.10 seconds = 1030.12 MB/sec
> > >     Timing buffered disk reads:  174 MB in  3.03 seconds =  57.41MB/sec
> > >
> > >
> > > The chached reads dropped by ~469MByte/s. The buffered reads are
> > > nearly the same.
> >
> > The buffered reads are all we care about.  They are the actual reads
> > from the disk to RAM.  The cached reads is just a repeated read of the
> > same sector of the disk, so today is really just a test of your memory
> > bandwidth.  Since we are loading memory and the CPU pretty heavily for
> > this test, and significant drop is to be expected.
>
>   Ok...sounds good -- in the sense of: It seems, that I have no
>   hardware problem anywhere in my Linux box...
>
> > So, it is not CPU utilization that is hurting your performance.
>
>   ( :) imaging the above sentence *WITHOUT* the current context :) )
>
>   This is the eigth wonder of the world...the first time when CPU load
>   does *not* hurt system performance! Oh yeah! I will send all my
>   render tasks to the...floppy controller, hahahahahahaa :))))))
>
>   (sorry could not resist...I am a little daft this morning as it seems
> :O))
>
> > You mentioned problems compiling.  The most likely case I can think of
> > is that you do not have enough memory, and are inducing the system to
> > swap.
>
>   Hmmm...1GByte Dualchannel-RAM should be enough for compiling Blender
>   (for example).
>
> > Indeed when compiling most programs, you should see very little
> > if any disk activity.
>
>   My SATA disk (Seagate ST3200827AS) is heavily shakeing its head when
>   compiling...
>
> > This is particularly suspect if you have
> > something like MAKEOPTS=-j4.
>
>   Yes, normally I use "make -j 4" for useing both cores.
>
>   May be I foolishly forget something to switch on or off in my BIOS
>   while migrating from PATA to SATA ? The only PATAs in my system is a
>   Plextor CD reader/burner and a LG DVD reader/burner on IDE1
>   (scnd. channel).
>
>   My mobo is a ASUS AV8 with AMI BIOS (upgraded to the "newest"
>   version I could find on the net).
>
> > Regards,
> > -Richard
> > --
> > gentoo-user@gentoo.org mailing list
> >
> --
> gentoo-user@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 5637 bytes --]

Re: [gentoo-user] SATA tuning ?

[Richard Fish]

Sigh.  Apologies for corrupting the thread by creating a new message,
but I seem to have finally been bit by the "missing emails" issue, so
I don't have a message to reply to.  I found this in the archives:

>> You mentioned problems compiling.  The most likely case I can think of
>> is that you do not have enough memory, and are inducing the system to
>> swap.

>  Hmmm...1GByte Dualchannel-RAM should be enough for compiling Blender
>  (for example).

Maybe not.  With -O3 FEX, some programs can take 200-400MB *per
module* to compile.  It all depends on the complexity of the code, and
the problem would be particularly acute with C++ programs (which I
know blender is not C++, so this is just something to keep in mind).

>> Indeed when compiling most programs, you should see very little
>> if any disk activity.

>  My SATA disk (Seagate ST3200827AS) is heavily shakeing its head when
>  compiling...

Run top in another window while this is going on, and keep an eye on
your swap usage.  If you see any swap being used at all, that is a bad
thing.

>> This is particularly suspect if you have
>> something like MAKEOPTS=-j4.

> Yes, normally I use "make -j 4" for useing both cores.

Try with -j2.  -j3 is ideal for keeping a dual-core CPU busy, but will
still take a huge amount of RAM, so unless you add another GB of RAM,
I recommend no more than -j2.  And if you are about to compile a big
C++ package (like KDE or OOo), drop to -j1.

-Richard
-- 
gentoo-user@gentoo.org mailing list