Messages in this thread | | | From | Benno Senoner <> | Subject | Re: lantency scheduling benchmarks of audio playing tasks during high disk I/O | Date | Mon, 21 Jun 1999 15:33:11 +0200 |
| |
On Mon, 21 Jun 1999, Andrea Arcangeli wrote: > On Mon, 21 Jun 1999, Benno Senoner wrote: > > >--------------+-------------+---------------+-------------+--------------+ > >buffer size |proc (top) | disk write | disk copy | disk read | > >--------------+-------------+---------------+-------------+--------------+ > >2x1024(11.6ms)| 15.1ms (307)| 9610.0ms (221)| 20.5ms ( 2)| 867.3ms ( 10)| > ^^^^^^ ^^^^^ > Could you explain the meaning of the two fields? Which bench are you using > to generate the numbers?
2 fragments of 1024 bytes = 11.6ms
15.1ms is the maximum time difference between 2 consecutive write() to /dev/dsp and 307 times the time diff was greater than 11.6ms , therefore there were 307 sound drop outs.
I use my usual bench ( http://www.gardena.net/benno/linux/latencytest0.3.tgz )
the tableis generated by: ./runalltests filesize ( for filesize (in bytes) use a size of at least 2 times your RAM to avoid caching.
> > >the andrea patch behaves very well during disk copy (cp file1 file2) operations, > >but on write only , or read only operations , it gives extremely high > >latencies. > > This sounds to me as a bit weird. A copy always imply a read and a > write... so it should be the slower one. This made me to think that the > numbers got fooled by a far different working set across benchmarks run. > Is this possible?
Mybe the cause is that , issuing read and writes in sequence , cause your kernel to respond in more smoothly, because massive writes get interrupted by the read.
> > If not I would like if you could try without the wait_for_IO hack. >
ok, I will net you know, but I think your patches are not the definitive cure of the high-latency problems, due to the kernel locking issue.
regards, Benno.
- 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/
| |