Hi




I am interested in using liquorix source to build a kernel to use with Remastersys, specifically 2.6.36 which is problematic with aufs2 currently. I have read the .configs on the sources page and it appears as though aufs2 is present as a module but there is no aufs2-36 standalone patch yet...have you patched the patch??
Back to top

Yes, I'm using the patches available below:

livenet.selfip.com/ftp/debian/aufs2.1-36/

No one has given any feedback whether it does or doesn't work though so I can't promise it'll do anything.
Back to top

Hi,

Thanks for the reply, in further investigation and testing I can confirm that the kernel works with Remastersys (modified for Squeeze and using live-initramfs 0.177.1) and produces a bootable image with Unetbootin anyway. I develop AV Linux www.bandshed.net/AVLinux.html and have been struggling with this aufs2 "headache" for a couple of weeks. I also build my own custom Kernels and was quite intrigued to see how similar our configs were. I am going to test liquorix for the next couple of weeks. How do you feel about 3rd party distros using your Kernel? AV Linux is free but also contains non-GPL commercial demos like Renoise, Transcribe, and linuxDSP plugins, among others, some open-source folks don't like that.

Anyway let me know, I have to say not having to be a Kernel guru and a Linux multimedia distributor at the same time would be a relief to an already maxed out schedule. Of course if I started using liquorix I would also funnel donations upstream as a token of appreciation and to support your project. Thanks for your surely countless hours on this vital project!
Back to top

Hi GMaq, I have no problem with anyone using liquorix in their distribution. The goal of Liquorix is to create a standalone "distribution" kernel with the best configuration and best kernel source for desktop centric workloads. If you find the kernel to perform better (with your metrics) and handle your low latency requirements more graciously, then liquorix served its purpose!

A word of note, however... the current configuration of liquorix uses CFS over BFS. This is because there are some suspend bugs in Linux that BFS exploits unintentionally. Nvidia's binary graphics driver behaves abnormally, preventing me running 3d applications without terrible stuttering and hiccups when BFS is the runtime scheduler.

However, if you don't expect your users to suspend or run binary graphics drivers on your distribution, I would strongly suggest using BFS. Every latency sensitive application in your distribution should perform better since BFS handles its task deadlines more responsibly than CFS.

Thanks for giving Liquorix a chance! :)
Back to top

OK,

Thanks for that info, actually many AV Linux users utilize the included sgfxi for proprietary drivers so I'm glad you have selected CFS, Obviously latency is a selling point, but I find many people misunderstand it's importance, its even difficult to persuade them that -rt is not really a necessity anymore. Anyway some in depth testing should determine if it's too much of a compromise. I appreciate that you have enabled a lot of multimedia stuff, I enable pretty much all of it especially the audio cards and webcam stuff. Thanks again, looking forward to kicking the tires!
Back to top

Just for kicks I built a kernel with BFS and did a real-world case test here on my 'studio' laptop. I was hoping to find some improvements; I was disappointed. I used 2.6.36.1-dmz3 and only changed a few things in the config, as recommended by Con Kolivas. Here are the details:

Machine: Dell Latitude E5500, Intel Core2Duo P8400, 2.26Ghz, 2Gb ram, i915 video.
Audio interface: Two Presonus Firepods tested at 44100Hz; 32x3, 64x2, and 64x3 buffering. (64x3 yields just under 10ms round-trip latency)
Programs used: Ardour, Patchage, a VST reverb effect, and jack-delay (all in my normal workflow except for jack-delay, which measures round-trip latency.)

The verdict? BFS saw three x-runs in a four-minute song at the lowest buffering (but everything kept working), CFS only saw one after about three minutes (and then Ardour crashed). And jack-delay reported round-trip latency about .1 ms higher (all buffering settings) on the BFS kernel than on the CFS kernel.

Definitely not a scientific test, and BFS processes my audio just fine, but not quite as good as CFS. Oh, well...it was a fun test anyway...

Edit: I did not test the latency of any applications or effects; only jackd, ffado, and my firewire interface were in the loop. BFS may indeed yield lower latency if the audio chain runs through several more effects. But that is a test for another day.
Back to top

You're a brave man trulan,

Thanks for sharing that info, I was also curious but when I saw that nVidia wasn't going to be happy with BFS I l lost interest pretty quickly. Obviously as you said your test isn't completely scientific but it certainly indicates that scheduling type is a relatively minor factor in Audio latency and that is certainly good to know.
Back to top

Also note that the version of BFS in liquorix is the same on zen... which includes the fork-depth patch due to a few requests. If you look through the commit log, it was removed once. Then I got a request later that it reduced the responsiveness of a few desktops by removing the patch, so I put it back in.

Con Kolivas posted on his blog that he doesn't believe the feature is worth the loss in throughput. I can also imagine that because of the way processes are grouped together, latency can also increase since threads of a process will compete for resources within the process all the threads stemmed from. That may explain why you experienced more underruns in ardour versus CFS. Why CFS crashed though remains a mystery...

ck-hack.blogspot.com/2010/11/create-task-groups-by-tty-comment.html

I'm actually thinking of disabling the sched autogroup feature because Con is right. A lot of the interactivity problems that process grouping solves come from the user of a system. Optimally, you would want to renice or set the scheduling policy of the terminal that you'll be running batch tasks in before initiating tasks from to a high nice value or idle scheduling policy. This will prevent a processes spawned from this terminal from conflicting with the interests of other processes spawned on your desktop from buttons and other clickable items.

However, it seems that everyone is finding these patches very helpful so I'll keep them. I would also prefer not requiring any "nicing" on any of my tasks and the kernel just determining what I probably want high priority and what is low.
Back to top