Messages in this thread |  | | Subject | Re: [PATCH] Preemption Latency Measurement Tool | From | Robert Love <> | Date | 20 Sep 2001 23:17:28 -0400 |
| |
On Thu, 2001-09-20 at 18:51, Dieter Nützel wrote: > > Does your audio source depend on any files (eg mp3s) and if so, could they > > be moved to a ramfs? Do the skips go away then? > > Good point. > > I've copied one video (MP2) and one Ogg-Vorbis file into /dev/shm. > Little bit better but hiccup still there :-(
As I've been saying, the problem really shouldn't be disk I/O. I would think (and really hope) the readahead code can fit a little mp3 in memory. Even if not, its a quick read to load it. The continued blips you see are caused by something, well, continual :)
> dbench 16 > Throughput 25.7613 MB/sec (NB=32.2016 MB/sec 257.613 MBit/sec) > 7.500u 29.870s 1:22.99 45.0% 0+0k 0+0io 511pf+0w > > Worst 20 latency times of 3298 measured in this period. > usec cause mask start line/file address end line/file > 11549 spin_lock 1 678/inode.c c01566d7 704/inode.c
A single 11ms latency is not bad. Again, this looks OK.
> ******************************************************* > > dbench 16 + renice artsd -20 works > GREAT! > > *******************************************************
Great :)
> dbench 32 and above + renice artsd -20 fail > > Writing this during dbench 32 ...:-))) > > dbench 32 + renice artsd -20 > Throughput 18.5102 MB/sec (NB=23.1378 MB/sec 185.102 MBit/sec) > 15.240u 63.070s 3:49.21 34.1% 0+0k 0+0io 911pf+0w > > Worst 20 latency times of 3679 measured in this period. > usec cause mask start line/file address end line/file > 17625 spin_lock 1 678/inode.c c01566d7 704/inode.c
What do you mean failed?
-- Robert M. Love rml at ufl.edu rml at tech9.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |