From: Jonathan W. <jw...@ju...> - 2012-12-17 23:17:29
|
Hi Stefan > it's funny. under certain circumstances i can have a cpu-load of 90% > and even higher (reported by qjackctl/scide) without getting a > single xrun. but that's rare. much rather cpu-usage is indicated low > and then suddenly 90% resp. my server-monitor in scide starts > flipping. i don't know if it's a certain threshold that gets > exceeded or some processes create spikes, causing sudden cpu-usage. > basically it's pretty difficult to predict when things out of control. This all sounds rather strange. Do you have CPU frequency scaling active? If the CPU speed changes it can upset jackd in general and FFADO in particular. If not already the case, it might be worth locking your CPU to its fastest setting and re-testing. > oops... that was the wrong kernel > > stefan@scmbp:/usr/src/linux-headers-3.2.34-rt51+$ grep PREEMPT > /usr/src/linux-headers-3.2.34-rt51+/.config > CONFIG_TREE_PREEMPT_RCU=y > CONFIG_PREEMPT_RCU=y > CONFIG_PREEMPT_NOTIFIERS=y > CONFIG_PREEMPT=y > CONFIG_PREEMPT_RT_BASE=y > # CONFIG_PREEMPT_NONE is not set > # CONFIG_PREEMPT_VOLUNTARY is not set > # CONFIG_PREEMPT__LL is not set > # CONFIG_PREEMPT_RTB is not set > CONFIG_PREEMPT_RT_FULL=y > CONFIG_PREEMPT_COUNT=y > # CONFIG_DEBUG_PREEMPT is not set > # CONFIG_PREEMPT_TRACER is not set :-) I was surprised to see no indication of the realtime patch in there. Anyway, the above seems fairly typical for a realtime-patched kernel which has been configured for realtime operation. > well, there's no evidence of 'low latency' in that output but what's > the difference between 'low latency' and 'rt' anyway? A "low latency" kernel is one which has CONFIG_PREEMPT set to "y" without any CONFIG_PREEMPT_RT_* options set. Note that the CONFIG_PREEMPT_RT_* options are only present if the kernel has had the realtime patchset applied. A "low latency" kernel is therefore accessible using an unpatched kernel.org kernel. The realtime patchset is only needed if one is after the extended features which that patchset supplies (which includes lower scheduling latency among a number of other things). A plain "low latency" kernel uses features present in an unpatched kernel to lower the average scheduling latency offered by the kernel. An "RT" kernel adds code which offers low deterministic scheduling latencies; that is, an RT kernel is guaranteed to provide scheduling latencies below a particular value, making it suitable for hard-realtime tasks which demand scheduling latencies not lower than that guaranteed value. > >>>If there's too much work for the CPUs to do within a given time span even > >>>an RT-PREEMPT kernel can give xruns, but that takes some doing. > >> > ... > > > >It's hard to know since I'm totally unfamilar with the way macosx does > >things. It's worth pointing out here that when jackd runs under macosx it > >won't be using FFADO, and FFADO is the source for most of jackd's CPU > >cycles when running under Linux. A lot of the work done by jackd/FFADO in > >Linux becomes the responsibility of system drivers under macosx, and CPU > >load due to those won't show up in any of the qjackctl/scide CPU meters. > >While it's entirely possible that the macosx drivers may be more > >optimised than the FFADO ones, the "real" CPU load created by your software > >stack under macosx is likely to be somewhat higher than what your load > >meters indicate in the macosx environment. > > yes, that's certainly true. checking with top or ps reveals that > clearly. however, audio seems to be handled incredibly efficient. a > lot of cpu-usage is caused e.g. by guis in supercollider (though it > works well). Audio is one thing which macosx does do reasonably well. You do have to keep in mind that there will be some CPU overhead associated with the firewire interface and that this generally won't be reported to userspace. Therefore under macosx your actual CPU usage will be higher than what you are told, but I would expect it to be somewhat lower than under Linux. > >Another option is that the macosx supercollider binary may have been > >compiled with a higher degree of optimisation compared to the binary you're > >using under Linux. > > i'd rather doubt that. Tim has especially put a lot of effort in the > linux version of sc (which osx also profits from). I'm talking about the compiler flags supplied when the source code was compiled for the two different targets. The C code itself is undoubtedly very efficient, but different compiler optimisation settings can result in binaries which have vastly different performance characteristics. This can make a significant difference to the CPU load created by a particular program even if the source for that program has been hand-tweaked. > >A related question is how jackd and (perhaps more > >importantly) FFADO were compiled under Linux. I suspect that the FFADO > >you're using has been compiled with debug enabled, which will add a > >measurable amount to the CPU load demanded by it. Optimisation levels > >certainly don't explain the 67% difference you're observing between the two > >systems (ie: macos CPU load being 1/3 of that under Linux), but I expect to > >to be causing a measureable proportion of that. > > ho do i find out if ffado has been compiled in debug-mode? We should have something in ffado-diag which tells us this, but I don't think we do. I think the easiest way is to start jackd in a way which requests debug output from FFADO, and see whether you get additional output that you don't normally see. In other words, compare the output of jackd -d firewire with jackd -d firewire -v 4 If the outputs are the same it means your FFADO was not compiled with debug support. Debug support not only omits calls to print debug output messages, but also activates the "-O2" optimisation level with gcc. Together these can shave measureable percentages from the CPU usage of jackd/ffado. > >>however, if raise the work-load (by e.g. stretching envelopes in > >>order i.e. create more overlapping in grains) cpu-usage explodes. > > > >When you say "cpu-usage explodes" what do you mean? Are we talking about > >the supernova process hitting 100%? Does the jackd process suddenly > >increase its CPU usage (I think it's unlikely, but we'll cover all bases)? > > i think i made a mistake in my code - synths weren't released > properly. nevertheless, as already said earlier it's pretty > difficult to predict when cpu-usage lifts off. then the machine > tends to produce lots of xruns. i'm not sure whether this results > from some process creating spikes in cpu-usage or just by exceeding > some threshold. Is there any possibility that you could be seeing the effects of denormals on your code? > >Out of interest, how do other jack applications behave on your system? > > i haven't yet much experience with other programs. just a bit with > audacity which worked. i'm sometimes using ardour in combination > with sc but haven't yet dared to try that under linux. Fair enough. > also, i'm now confronted with a new problem: i can't compile > supercollider anymore due to missing jack/jack.h - i think that > header got lost somehow during my experiments. i guess the headers > can be obtained by installing libjack-dev but doing so would force > the deinstallation of jack2 etcetc.... sorry, i know this not a > jack-list. i'm going to try to figure it out. You are correct: you will require the a jack dev package of some sort. What jack package do you have installed now? If it's jack2, I would expect there to be a libjack2-dev package (or a name to that effect) which would not force the jack2 package off the system. Regards jonathan |