Re: scheduling latencies, [patch] `cp /dev/zero /tmp' (patch against 2.2.9)

Benno Senoner (sbenno@gardena.net)
Fri, 18 Jun 1999 00:06:47 +0200

On Thu, 17 Jun 1999, Alan Cox wrote:
> > The process does only sit in a loop and write() data from RAM to /dev/dsp
> > ( RT FIFO scheduled),
> > and in background I call scripts which write / copy / read from/to large files,
> > trying to disturb the RT thread.
> > Obviously my disk I/O processes are scheduled without realtime priority.
> >
> > The scheduling latencies on Linux go up to 70-130ms on pretty high end HW.
>
> What hard disk controller, if its IDE how is it tuned (DMA/UDMA, irq masked ?)
> If it is a random socket7 board what fairness settings have you got in the
> BIOS as by default on some of these boards IDE DMA can hog the entire bus.
>
> Alan

PII 400 + Mainboard Asus P2B BX Chipset, with a IBM Deskstar 16GB UDMA as
/dev/hdc

tu tune the disk I enabled all useful features:

multicount , DMA , unmask IRQs , enable 32 bit support

/sbin/hdparm -m 8 -d 1 -u 1 -c /dev/hdc

note that windoze is able to get the 20ms latency with my machine , using a
software synthesizer, and copying a file in the background,
Maybe they use some hacks like IRQ programming, but I think with clever
scheduling , you can reach similar results using RT processes.

try my benchmark yourself:

http://www.gardena.net/benno/linux/latencytest0.3.tgz

to note that heavy access to the /proc filesystem (using top -d 0.01 ) causes
audio drop outs too, not so long as disk access, in the range of 15ms , but that
seems a bit high for me.

we really need an *UGLY* (but useful) hack which allows the write() to
soundcards, to skip some locks of the I/O layer, since audio writes are
completely unrelated to disk I/O , but I have no idea how hard it would be to
implement such a mechanism.

let me know if there are new advances in this area !

regards,
Benno.

sbenno@gardena.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/