ok. The preemption patch helps realtime applications in linux be a little
more close to realtime. I understand that. But your mp3 player shouldn't
need root permission or renicing or realtime priority flags to play mp3s. To
test how well the latency patches are working you should be running things
all at the same priority. The main issue people are having with skipping
mp3s is not in the decoding of the mp3 or in the retrieving of the file, it's
in the playing in the soundcard. That's being affected by dbench flooding
the system with irq requests. I'm inclined to believe it's irq requests
because the _only_ time i have problems with mp3s (and i dont change priority
levels) is when A. i do a cdparanoia -Z -B "1-" or dbench 32. I bet if
someone did these tests on scsi hardware with the latency patch, they'd find
much better results than us users of ide devices.
even i dont get any skips when i run the player at nice -n -20. That
doesn't tell you much about the preemption patch though. And it doesn't tell
you about performance when you dont give linux the chance to do what it does,
multitask. That's where the latency patch is directed at improving, i
think.
On Saturday 22 September 2001 17:09, Dieter Nützel wrote:
> Am Freitag, 21. September 2001 17:48 schrieb george anzinger:
> > Robert Love wrote:
> > > 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 :)
> >
> > Are you running your application at some real time priority? I suspect
> > that, when dbench starts, it floods the system with a lot of new tasks
> > and the system must visit each one until it gets back to your ap. Nice
> > will only do so much here. Real time priority is the way to go.
> > Attached are a couple of small programs to help here. "rt" runs a given
> > ap at a given priority. I.e. > rt 10 foo, runs foo at priority 10.
> > (There are more options, try rt -h.) getrt reports the priority of a
> > task. If you do something like > rt 10 bash everything you run from
> > the new bash prompt will be at priority 10. You must be root to run rt
>
> Yes, I do like I've posted in all the related threads.
>
> Here is some more input for you. I hope it could help nail it down.
>
> Regards,
> Dieter
>
> BTW I'll now switching to 2.4.10-pre14
>
> SunWave1#time tar xIf /Pakete/Linux/linux-2.4.9.tar.bz2
> 34.570u 5.350s 0:47.84 83.4% 0+0k 0+0io 295pf+0w
>
> I "hear" some have disk activities (disk trashing).
>
> SunWave1#sync
>
> Runs for ages!!!
>
> User CPU 0%
> System CPU 0%
> Idle CPU 99%
>
> So where did it wait???
>
> Here comes what latencytimes show:
>
> Worst 20 latency times of 5061 measured in this period.
> usec cause mask start line/file address end line/file
> 322263 reacqBKL 1 1375/sched.c c01138b4 697/sched.c
> 216174 BKL 1 30/inode.c c016b971 52/inode.c
> 158328 BKL 9 742/block_dev.c c0144d51 697/sched.c
> 66975 BKL 1 1101/super.c c014250d 697/sched.c
> 53560 BKL 1 1101/super.c c014250d 1130/super.c
> 37742 spin_lock 1 547/sched.c c0111b04 795/block_dev.c
> 24822 spin_lock 1 678/inode.c c01551f7 704/inode.c
> 24739 spin_lock 1 291/buffer.c c014003c 285/buffer.c
> 19330 spin_lock 1 547/sched.c c0111b04 697/sched.c
> 16566 BKL 1 30/inode.c c016b971 697/sched.c
> 14049 spin_lock 1 2043/tcp_ipv6.c e9078837 119/softirq.c
> 11993 spin_lock 1 2111/tcp_ipv4.c c0220517 119/softirq.c
> 11704 BKL 1 706/block_dev.c c0144bd7 1381/sched.c
> 11405 spin_lock 1 291/buffer.c c014003c 280/buffer.c
> 11288 BKL 1 706/block_dev.c c0144bd7 697/sched.c
> 11213 reacqBKL 9 1375/sched.c c01138b4 696/block_dev.c
> 11212 spin_lock 1 547/sched.c c0111b04 696/block_dev.c
> 7552 spin_lock 1 298/buffer.c c013bb1c 285/buffer.c
> 5013 BKL 0 2763/buffer.c c013fbca 697/sched.c
> 4641 BKL 1 1302/inode.c c016de79 697/sched.c
>
> SunWave1#ksymoops -m /boot/System.map -A " c01138b4 c016b971 c0144d51
> c014250d c014250d c0111b04 c01551f7 c014003c c0111b04 c016b971 e9078837
> c0220517 c0144bd7 c014003c c0144bd7 c01138b4 c0111b04 c013bb1c c013fbca
> c016de79"
> ksymoops 2.4.3 on i686 2.4.10-pre12-preempt. Options used
> -V (default)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -o /lib/modules/2.4.10-pre12-preempt/ (default)
> -m /boot/System.map (specified)
>
>
> Adhoc c01138b4 <preempt_schedule+34/b0>
> Adhoc c016b970 <reiserfs_delete_inode+30/110>
> Adhoc c0144d50 <blkdev_close+60/1b0>
> Adhoc c014250c <kill_super+ac/280>
> Adhoc c014250c <kill_super+ac/280>
> Adhoc c0111b04 <schedule+34/550>
> Adhoc c01551f6 <prune_icache+36/160>
> Adhoc c014003c <kupdate+11c/210>
> Adhoc c0111b04 <schedule+34/550>
> Adhoc c016b970 <reiserfs_delete_inode+30/110>
> Adhoc e9078836 <[ipv6]tcp6_get_info+4a6/770>
> Adhoc c0220516 <tcp_get_info+4b6/7a0>
> Adhoc c0144bd6 <blkdev_put+46/160>
> Adhoc c014003c <kupdate+11c/210>
> Adhoc c0144bd6 <blkdev_put+46/160>
> Adhoc c01138b4 <preempt_schedule+34/b0>
> Adhoc c0111b04 <schedule+34/550>
> Adhoc c013bb1c <wait_for_locked_buffers+3c/60>
> Adhoc c013fbca <sync_old_buffers+2a/130>
> Adhoc c016de78 <reiserfs_dirty_inode+58/f0>
>
> -
> 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/
-
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:51 EST