<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>thanks for all your input, I’ll try and summarize here.</div><div><br class=""></div><div><br class=""></div><div><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" class="">You're running Mint :-) Lots of background bells and whistles there, lots of things which will crop up and interfere, things you cannot disable or turn off with absolute certainty. If you want smooth power, you'll have to choose more carefully. My current SOP in more detail here:<br class=""><br class=""><a class="moz-txt-link-freetext" href="http://lsn.ponderworthy.com/doku.php/choosing_a_linux_platform_for_live_synth">http://lsn.ponderworthy.com/doku.php/choosing_a_linux_platform_for_live_synth</a><br class=""><br class=""><br class=""><br class=""><div class="moz-signature">-- <br class=""><div class="" style="color: rgb(153, 51, 0); font-size: 0.8em; font-style: italic;">Jonathan E. Brickman <a class="moz-txt-link-abbreviated" href="mailto:jeb@ponderworthy.com">jeb@ponderworthy.com</a> (785)233-9977<br class="">Hear us at <a href="http://ponderworthy.com/" class="">http://ponderworthy.com</a> -- CDs and MP3 <a href="http://ponderworthy.com/ad-astra/ad-astra.html" class="">now available!</a><br class="">Music of compassion; fire, and life!!!</div></div></blockquote><div class="moz-signature"><div class=""><br class=""></div></div></div></div><div><br class=""></div><div>First of all, booting into console mode, rather than running the full blown desktop seemed to eliminate most of the problems, although it’s still not quite a stable as i’d like.</div><div>Also i don’t quite understand how all of that could interfere with my RT-thread.</div><div>This was going to try and install a more minimal system anyway, and don’t need a graphical environment for this, but during developments it’s kind of nice to have.</div><div><br class=""></div><div>I still would like to see how far i can take this, and was really hoping i can continuously use 80-90% of all cpu cores without dropouts…</div><div>Is that realistic with a lowlatency kernel? </div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div>Do you lock all memory used by your RT threads ? <br class=""><br class="">If you don't and the system is configured for high swappiness<br class="">[1] this sort of thing could happen. <br class=""><br class="">I'm routinely running big real-time convolution matrices without<br class="">problems, so it's certainly possible. <br class=""><br class=""><br class="">[1] <<a href="https://en.wikipedia.org/wiki/Swappiness" class="">https://en.wikipedia.org/wiki/Swappiness</a>><br class=""><br class="">-- <br class="">FA<br class=""></div></blockquote><div><br class=""></div><div>I am not currently locking memory. I thought a had plenty of ram, as not to cause any swapping, but i guess its good practice to wire memory, so i will give it a try.</div><div><br class=""></div><blockquote type="cite" class=""><br class="">Bad kernel driver? WIFI drivers are known bad for things like this. An interupt driver can block if it is designed badly. I found on one machine I had to unload the the kernel module for my wifi as it actually created more problems when I turned the power off to the tx than when it was on. (it seems to me on my wifi, when it was turned on I got xruns every 5 seconds, but with it turned off it was every half second or so... sounds very close to 0.6, unloading the kernel module fixed it)<br class=""><br class="">Cron should also be turned off, but that is probably not the problem here. Cron runs super "nice" but there seem to be some things it does like packge update that can cause problems too. I turn off cron while recording.<br class=""><br class="">--<br class=""><div>Len Ovens</div></blockquote><div><br class=""></div><div>I don’t have a wireless on my machine, nor an nvidia card. just intel builtin graphics. This where my linux knowledge falls short, but If i don’t have that hardware, can I assume no drivers for it are loaded?</div><div><br class=""></div><div></div><blockquote type="cite" class=""><div><br class="">AFAIK, the important things are.<br class=""><br class="">1. Use a properly configured realtime patched kernel.<br class=""><br class=""></div></blockquote><div class=""><br class=""></div><div class="">lowlatency-kernel is not going to cut it?</div><div class=""><br class=""></div><div class="">I wasn’t really able to find to much info on the difference between the two, other than than the rt-kernel is a “step up” and hard realtime vs soft.</div><div class="">But nothing on how this is technically achieved</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div>2. Set a high priority of the soundcard interrupt, something like 97 is<br class="">a good value. (If using a USB soundcard, set the priority of the<br class="">interrupt servicing the USB hub instead).<br class=""><br class=""></div></blockquote><div class=""><br class=""></div>did that.<br class=""><blockquote type="cite" class=""><div>3. Run Jack with realtime and memlocking enabled and at a priority of<br class="">80.<br class=""><br class=""></div></blockquote>I’m not running jack but rather using alsa directly/<br class=""><br class=""><blockquote type="cite" class=""><div>4. Make sure that you don't have any hardware/drivers that play havoc<br class="">with your kernel scheduling. some WIFI adapters, NVIDIA, etc comes to<br class="">mind.<br class=""><br class="">5. Make sure that the system isn't suffering from SMI/NMIs which<br class="">preempt the kernel and can take a long time to execute. This can be<br class="">done with hwlatdetect script in the rt-tests package.<br class=""><br class="">6. Use cyclictest from rt-tests to confirm that there are no latency<br class="">spikes in how the kernel schedules threads.<br class=""><br class="">Possibly hyperthreading, cpu power management, etc could cause<br class="">problems, and I don't have experience with all hardware out there, but<br class="">IME on modern Intel hardware this isn't a problem.<br class=""><br class=""></div></blockquote><div class="">I did actually find that hyperthreading had an impact, turing it of made every thing much more predictable.</div><br class=""><blockquote type="cite" class=""><div>JACK2 also has a very nice profiling tool that can give a good idea<br class="">about what is going on with the soundcard interrupt, clients, etc.<br class=""><br class="">-- <br class=""><br class=""> Joakim</div></blockquote><div><br class=""></div><div><br class=""></div><div><div class=""></div><blockquote type="cite" class=""><div class="">Keep an eye on the interrupts while its all running, particularly<br class="">Non-maskable interrupts. Try to correlate them with the 0.6 sec<br class="">of the glitches if possible;<br class=""></div><div class=""><br class="">watch -n 0.1 cat /proc/interrupts<br class=""></div><div class=""> <br class=""></div><div class="">I've written up some of the checks I generally do, perhaps browse<br class="">that to see if there's anything there that you could check?<br class=""><a href="http://openavproductions.com/real-time-latency-tuning/" class="">http://openavproductions.com/real-time-latency-tuning/</a><br class=""><br class=""></div><div class="">Thats all I can think of at the moment, -Harry<br class=""></div><div class=""><br class=""></div></blockquote><div class=""><br class=""></div></div><div>Here’s the output of cat /proc/interrupts:</div><div><br class=""></div><div><br class=""></div><div><div style="margin: 0px;" class=""><div style="margin: 0px;" class=""> CPU0 CPU1 CPU2 CPU3</div><div style="margin: 0px;" class=""> 0: 57 0 0 0 IO-APIC-edge timer</div><div style="margin: 0px;" class=""> 1: 3 0 0 0 IO-APIC-edge i8042</div><div style="margin: 0px;" class=""> 7: 44 0 0 0 IO-APIC-edge</div><div style="margin: 0px;" class=""> 8: 1 0 0 0 IO-APIC-edge rtc0</div><div style="margin: 0px;" class=""> 9: 3 0 0 0 IO-APIC-fasteoi acpi</div><div style="margin: 0px;" class=""> 12: 4 0 0 0 IO-APIC-edge i8042</div><div style="margin: 0px;" class=""> 16: 0 0 0 0 IO-APIC 16-fasteoi madifx</div><div style="margin: 0px;" class=""> 121: 7074 0 0 341 PCI-MSI-edge xhci_hcd</div><div style="margin: 0px;" class=""> 122: 13001 25946 0 342 PCI-MSI-edge 0000:00:17.0</div><div style="margin: 0px;" class=""> 123: 3409 0 0 0 PCI-MSI-edge eth0</div><div style="margin: 0px;" class=""> 124: 171029 0 0 0 PCI-MSI-edge i915_bpo</div><div style="margin: 0px;" class=""> 125: 4805 0 0 0 PCI-MSI-edge snd_hda_intel</div><div style="margin: 0px;" class=""> NMI: 17 12 13 14 Non-maskable interrupts</div><div style="margin: 0px;" class=""> LOC: 544121 436328 444080 462821 Local timer interrupts</div><div style="margin: 0px;" class=""> SPU: 0 0 0 0 Spurious interrupts</div><div style="margin: 0px;" class=""> PMI: 17 12 13 14 Performance monitoring interrupts</div><div style="margin: 0px;" class=""> IWI: 0 0 0 0 IRQ work interrupts</div><div style="margin: 0px;" class=""> RTR: 3 0 0 0 APIC ICR read retries</div><div style="margin: 0px;" class=""> RES: 13051 11975 11216 8004 Rescheduling interrupts</div><div style="margin: 0px;" class=""> CAL: 613 547 560 526 Function call interrupts</div><div style="margin: 0px;" class=""> TLB: 640 767 676 535 TLB shootdowns</div><div style="margin: 0px;" class=""> TRM: 0 0 0 0 Thermal event interrupts</div><div style="margin: 0px;" class=""> THR: 0 0 0 0 Threshold APIC interrupts</div><div style="margin: 0px;" class=""> MCE: 0 0 0 0 Machine check exceptions</div><div style="margin: 0px;" class=""> MCP: 31 31 31 31 Machine check polls</div><div style="margin: 0px;" class=""> HYP: 0 0 0 0 Hypervisor callback interrupts</div><div style="margin: 0px;" class=""> ERR: 44</div><div style="margin: 0px;" class=""> MIS: 0</div><div class=""><br class=""></div></div><div class="">the local timer interrupts are getting fired all the time, but i guess they should.</div><div class="">123 eth0 is also updated rather often. But the one thats closed to 0.6s seems to be:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px;" class=""> 122: 13001 26147 0 342 PCI-MSI-edge 0000:00:17.0</div></div><div class=""><br class=""></div><div class="">But is there anything a can do about that?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">cheers,</div><div class="">Fokke</div><div class=""><br class=""></div></div><div><br class=""></div><div><br class=""></div></body></html>