Re: [linux-audio-dev] latency problem bdflush related?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] latency problem bdflush related?
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Nov 21 2001 - 23:58:23 EET


>Potential reason:
>-----------------
>The Problem seems to be related to meta data buffer flushes of the bdflush
>daemon. I have expterimented with different settings of /proc/sys/vm/bdflush
>and seen that value 4 (the percentage of cache to scan for free clusters)
>can change the rate of xruns. smaller values mean a higher xrun rates.

its not entirely clear from your output whether you are successfully
running jackd as a realtime process. you've used the -R flag, but the
call to mlockall() is failing with ENOMEM. this means the program's
text and data is not physically locked into RAM, which means that it
could get paged, which will always cause an xrun with 128 frames per
interrupt.

its not clear why your system denies mlockall: ENOMEM means:

  RETURN VALUE
       On success, mlockall returns zero. On error, -1 is
       returned, errno is set appropriately.

  ERRORS
       ENOMEM The process tried to exceed the maximum number of
              allowed locked pages.

jackd is not that big. i am not that sure what sets this limit
(anybody else know?) but i am suprised to see you run into it. i've
never seen it, and i lock Ardour into physical RAM, which is
*gigantic* compared to jackd (its an entire Gtk-- GUI!!)

kernels 2.4.4-2.4.13 are known to have serious VM issues.

kernels 2.2.X have even worse VM issues. also, your alpha kernel is
apparently unpatched, and with 128 frames per interrupt, i very much
doubt a standard 2.2 series kernel stands a hope in hell of satisfying
the scheduling requirements.

i would suggest you first try to resolve the issue with mlockall not
working. then consider moving forward to 2.4.15 or backwards. i
generally use 2.4.0 and will continue to do so until i see clear signs
that the VM wars have finished *and* that a working VM system is in
place. we have not had a working VM system in place for more than a
year now, although 2.4.0 is pretty good for realtime audio work.

frankly, i'd like to be able to turn the entire VM system off
sometimes. its completely irrelevant when running real-time apps
anyway.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Nov 21 2001 - 23:51:20 EET