Re: [PATCH] Preemption Latency Measurement Tool

From: Robert Love (rml@tech9.net)
Date: Thu Sep 20 2001 - 22:17:28 EST


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/



This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:41 EST