# bad disk i/o performance

## albright

Hi everybody. Let's say that I'm combining a bunch of vob files together

for subsequent transcoding using cat *.vob > out.vob.

I find that during this process the system gets **very** unresponsive. It

takes many seconds to open a browser window or even a terminal.

top reports that it is the i/o wait state that is taking up the system

resources.

Is there a way to fix this. Nicing the cat does not help much. Is this 

an inherent weakness of ide disk controllers? Is there some way

to force cat to write *slowly* to the disk (the overall speed of the

process does not matter much to me - I'd rather have it slow in the

background with a responsive foreground system).

I know this question isn't very precise or clear, but there it is ...

----------

## NeddySeagoon

albright,

Run hdparm /dev/<your-drive> -tT and post the results please. 

Also post the IDE line from your lspci output.

----------

## toxictux

 *albright wrote:*   

> Hi everybody. Let's say that I'm combining a bunch of vob files together
> 
> for subsequent transcoding using cat *.vob > out.vob.
> 
> I find that during this process the system gets **very** unresponsive. It
> ...

 

First make sure you are getting all you can from your drive.

A good hdparm settings would be:

```

hdparm -X69 -d1 -u1 -m16 -c3 /dev/hdX

```

(of course /dev/hdX should be replaced with your actual drive)

This will set the drive to UDMA-5 (ATA100) mode with other speed goodies (like 32bit I/O, multicount reads....).

We are talking IDE here, right? What are your system specs?

----------

## superstoned

you're right, this can be seen as a fault (i do...) in the kernel. the io scheduler isn't very good in keeping everything interactive. its very simple, acutally - mostly who asks first gets first. there is work being done on this. you might try the -ck sources, or -cko, they contain the timesliced CFQ scheduler for the kernel. timesliced CFQ (completely fair scheduler with support for timeslices to prevent an io-operation to take too long) should really make your system more responsive. I think ts-cfq will be in the new 2.6.12, maybe as default. you can also swithc scheduler on the fly, try 

echo cfq > /sys/block/hda/queue/scheduler

(cat /sys/block/hda/queue/scheduler to see which is used. you also see which are available. experiment with this first, i think you might have cfq already, but it's not the default. try it!)

or boot with

elevator=cfq added to your kernel parameters.

----------

## NeddySeagoon

superstoned,

I suspect the scheduler will make very little difference to this problem. Firstly, any task blocking on I/O should give up the CPU anyway. More importantly, IDE commands cannot be queued or overlapped on the same IDE cable, so once a read/write is in progress it must complete before the next (IDE) command can be issued.

I suspect the issue here is that DMA is not in use, so the CPU is heavily involved in data transfers to/from disk, rather than just setting up the DMA and getting on with another process.

----------

## albright

here's the hdparm info (by the way, I'm doing this while tcextract is

pulling the video stream from a vob file - it took 15 seconds from pushing

the "post reply" button until I could start writing this ...  :Sad:  )

You can see dma is enabled and the disk uses mode udma5

/dev/hda:

 multcount    = 16 (on)

 IO_support   =  1 (32-bit)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 19457/255/63, sectors = 312581808, start = 0

 Model=WDC WD1600JB-00GVA0, FwRev=08.02D08, SerialNo=WD-WCAL92796025

 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }

 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74

 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16

 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455

 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}

 PIO modes:  pio0 pio1 pio2 pio3 pio4

 DMA modes:  mdma0 mdma1 mdma2

 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5

 AdvancedPM=no WriteCache=enabled

Here are the results of hdparm -Tt

/dev/hda:

 Timing buffer-cache reads:   928 MB in  2.00 seconds = 462.91 MB/sec

 Timing buffered disk reads:  166 MB in  3.01 seconds =  55.08 MB/sec

These look pretty good to me ...

----------

## NeddySeagoon

albright,

That looks good. What does top say about memory and swap use when your vob copy is in progess.

Post about the first 8 lines please.

----------

## albright

thanks for the help

Here is the output of top while running

cat *.vob > new.vob

(While doing this it took at least 20 seconds for konqueror to

start )

Note the wa state 

top - 13:01:37 up 50 min,  1 user,  load average: 1.71, 0.45, 0.15

Tasks:  96 total,   2 running,  94 sleeping,   0 stopped,   0 zombie

Cpu(s): 14.3% us,  9.3% sy,  0.0% ni,  0.0% id, 75.7% wa,  0.7% hi,  0.0% si

Mem:    516020k total,   512420k used,     3600k free,     1900k buffers

Swap:   722884k total,      216k used,   722668k free,   324896k cached

maybe this is just as good as linux gets under this kind of load

with ide disks ...  :Sad: 

btw, the system is an athlon 1700+ with 512 mb memory, a 160gb western

digital "caviar" ide hard drive, a 60 gb western digital secondary (slave)

drive (not involved in this process and sound asleep in fact), a dvd burner

and dvd-rom drive on secondary ide as master and slave ...

2.6.8 kernel

----------

## NeddySeagoon

albright,

I have a feeling that cat does a byte at a time copy, which is really not what you want.

I'm surprised by how little memory is allocated to buffers. I would have expected everything swappable to be swapped out and most of memory to be allocated to buffers. You can't swap out dirty buffers.

There must be a better way than cat of doing this but it escapes me at the moment,

----------

## flash49

You could try changing the "kernel io scheduler":

```

bash-2.05b# cat /sys/block/hda/queue/scheduler

noop [anticipatory] deadline cfq

bash-2.05b# echo "cfq" > /sys/block/hda/queue/scheduler

```

Looking at the description of the default anticipatory scheduler (part of the kernel source) this one seems to be the worst choice for you.

----------

## albright

thanks for the scheduler tip; switching to cfq makes a substantial

improvement. It still takes a long time to open new apps while

cat (or tcextract or tcrequant or dvdauthor) are running but they

are *much* more responsive once they get going ...

----------

## superstoned

 *albright wrote:*   

> thanks for the scheduler tip; switching to cfq makes a substantial
> 
> improvement. It still takes a long time to open new apps while
> 
> cat (or tcextract or tcrequant or dvdauthor) are running but they
> ...

 

hehe  :Very Happy: 

just as i expected... now expect timesliced cfq to be even better than plain cfq!!!

----------

## bollucks

Add to that the I/O priorities supported by cfq-ts so that "nice" actually helps tar even since ionice is linked to cpunice by default. -ck based kernels have cfq-ts included and enabled by default.

----------

## superstoned

 *bollucks wrote:*   

> Add to that the I/O priorities supported by cfq-ts so that "nice" actually helps tar even since ionice is linked to cpunice by default. -ck based kernels have cfq-ts included and enabled by default.

 

the nice support has been dropped, mostly. as you can read in this mail from jens axboe to the -ck mailinglist:

 *Quote:*   

> 
> 
> Hi,
> 
> A new release of cfq-ts. The big change this time is that I decided to
> ...

 

so there are no real priorities anymore. the better interactivity compared to the 'old' cfq is mostly because of the timeslices - a process can't hold the IO for too long. AFAIK  :Very Happy: 

----------

## bollucks

Sorry but you missed the point of his email. write I/O priority support was dropped. Read support is still there.

----------

## superstoned

 *bollucks wrote:*   

> Sorry but you missed the point of his email. write I/O priority support was dropped. Read support is still there.

 

you're right. this does not have very much to do with the problem, I didn't read it very well... its more the timeslices that help:

 *Quote:*   

> I'm just playing around for now, but this cfq version will reserve time
> 
> slices for each queue in the system. You can tweak it with 'slice' and
> 
> 'idle' in the sysfs iosched directory for any given drive:
> ...

 

you can twiddle with these, by reducing or increasing some of these values.

----------

