Ubuntu 11.10 vs. Mac OS X 10.7.2 Performance

[liam]

LOL.



I'll see if i can dig up a link or some info. Like i said i thought i had heard it was 'Lion' specific, which means it's somewhat newer, but who knows, maybe i am just confused.



IO kit is good...so is having a stable ABI for developers to work with.... I think a lot of drivers in linux are very buggy, and is one area where linux is lacking.



Ah, you found CCRMA. - I used to used that repo for audio stuff, when i used Fedora (it was my distro for a couple of years). the CCRMA rt-kernel should work nicely, the guy from Stanford University who maintains that repo knows his stuff. Beyond that you could always compile it yourself ~ i do every time a new RT release comes out. ~ But the difference being, since i use Archlinux, and more specifically the AUR -> compiling linux-rt and installing it is very straight forward, it would be like using 'yum install XYZ' in fedora. one quick command + compile time... it's that easy



PA wont ever replace Jackd. Jack provides a lot of stuff that PA simply doesn't do. Jack at this point has a lot of users (not only in Linux, but also Windows and OSX) and a lot of applications built with jack in mind (mainly linux ones, though). I can't see PA taking over that. I wouldn't want it to anyway. PA is never allowed to exist on my Linux boxes.



Ya, i know what you mean. but PA isn't targeted for Proaudio, and ALSA is obviously a requirement (at least in the kernel). I personally wished ALSA had been fixed rather than introducing PA.... on the Jackd front - some commercial Proaudio software is starting to target Linux though. Aside from Harrison mixbus (ardour-based) and Renoise ... BitWig Studio will be available for linux and will also support Jackd (just like Renoise does). BitWig looks very much comparable to Ableton Live - so Bitwig could be a game changer for some.



CONFIG_PREEMPT_RT_FULL=y ~ full preemption. I *am* running RT, not just PREEMPT.

Linux ninez 3.0-rt #1 SMP PREEMPT RT Sat Jan 31 22:28:24 EST 2011 x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux

As far as behavior, i use RT all the time and i don't use a generic kernel at all. I also use Jackd as my default sound server - ie: it runs all the time, no PA no ALSA - just JAckd The only time i've gotten funny/odd behavior out of this machine was once when i plugged in a USB-drive but Jackd/soundcard made file transfers 'ridiculously slow' (until i killed jack, and unplugged the soundcard). But it only happened the once, and actually made sense being as Jack/apps were using 60-70% of each core, and the sound device had the highest rt-priorities...



nope, but i'm gonna read about it now!

cheers

It's not clear that IO Kit provides any binary guarantees. At least, I haven't come across any such things yet. Their API, however, I'm guessing hasn't changed since Bush was in office (given that it is OOP, it's not to surprising that they don't care too much about the ABI). So a simple recompile should work in most instances, I'd imagine.
So, I tried CCRMA...my thinkpad froze twice over a several hour period. I uninstalled I might try compiling a kernel but it's just such a hassle with Fedora, especially since if I go to the trouble of compiling it, I feel I should buildin all the modules I would need, and that means finding out the names of everything I need. It's a whole big thing
Well, I honestly don't have anything invested in PA, but it seems to have the best chance of providing a CoreAudio experience on Linux. Pottering was heavily influenced by CA, and I've never heard anyone say that CA was anything but fantastic. Of course, Mac runs a preempt kernel, which is something desktop Linux really needs to do if it has any hope of providing for the "most" desktop users. I understand why Fedora won't do it (b/c it really hurts server performance, and that is Fedora's target), but I don't understand why Ubuntu/Mint or any other desktop focused distro would run anything other than the preempt kernel. Frankly, the preempt kernel might be enough for any use where throughput isn't the most inmportant thing, other than the embedded area, of course.
About ALSA, I'm going to repeat something I feel I've been saying a lot recently: "UNIX" is supposed to be composed a bunch of relatively independent components. From the sound side that should mean: a stable kernel API and a user-space sound server. If we can get rid of the non-driver framework related cruft of Alsa, and "finish" with PA (or replace it with something that does at least everything PA does), we should then have something pretty similar to OSX. I really wish I had the expertise in this area to help the PA, or whomever, guys...

Hmm, so you are running the Molnar branch. Isn't that a bit overkill? It's really more designed for hard RT work. Have you tried using a preempt kernel, and tweaking the knobs? You might find that the cpu would be less loaded if it wasn't running with the overhead of the RT kernel.
If you try it, let me know how it turns out.
You can PM me (I think) on Phoronix.

Best/Liam

[ninez]

It's not clear that IO Kit provides any binary guarantees. At least, I haven't come across any such things yet. Their API, however, I'm guessing hasn't changed since Bush was in office (given that it is OOP, it's not to surprising that they don't care too much about the ABI). So a simple recompile should work in most instances, I'd imagine.

MacOSX does provide a stable ABI for device drivers.

So, I tried CCRMA...my thinkpad froze twice over a several hour period. I uninstalled I might try compiling a kernel but it's just such a hassle with Fedora, especially since if I go to the trouble of compiling it, I feel I should buildin all the modules I would need, and that means finding out the names of everything I need. It's a whole big thing

It shouldn't be a huge hassle to compile a custom kernel in Fedora ~ i used to do that all the time. Your standard (fedora) kernel, has a .config that already will boot on your hardware, all you have to do is use that (ie: make oldconfig), then from there, all that you would need to do is enable the RT specific stuff and go through the config (ie: make menuconfig), disabling anything you don't want (as most default kernels have a wack of drivers NOT needed). After that, it should be as simple as 'make rpm' ~ then installing the .rpms later.

As an example, i used to use Zen-kernel in Fedora (has the BFS / BFQ patches, among other really good tweaks). Look how simple the instructions are;

http://zen-kernel.org/tutorials/dist...d-installation

Kernels only suck to compile in Fedora if you strictly follow Fedora documentation (which IMO is very convoluted)...

Well, I honestly don't have anything invested in PA, but it seems to have the best chance of providing a CoreAudio experience on Linux. Pottering was heavily influenced by CA, and I've never heard anyone say that CA was anything but fantastic. Of course, Mac runs a preempt kernel, which is something desktop Linux really needs to do if it has any hope of providing for the "most" desktop users. I understand why Fedora won't do it (b/c it really hurts server performance, and that is Fedora's target), but I don't understand why Ubuntu/Mint or any other desktop focused distro would run anything other than the preempt kernel. Frankly, the preempt kernel might be enough for any use where throughput isn't the most inmportant thing, other than the embedded area, of course.

PA may be modelled after CA in some sense, but it doesn't provide the same rich feature set. CoreAudio covers everything, it has Jack/ASIO like features, it has ALSA and PA type feature sets, handes MIDI, you can even aggregate multiple sound cards ~ all under one roof.

I'm pretty sure a lot of distro's ship with a PREEMPT kernel, just not a PREEMPT RT kernel. Fedora may not, but i am reasonably sure that Ubuntu does.

About ALSA, I'm going to repeat something I feel I've been saying a lot recently: "UNIX" is supposed to be composed a bunch of relatively independent components. From the sound side that should mean: a stable kernel API and a user-space sound server. If we can get rid of the non-driver framework related cruft of Alsa, and "finish" with PA (or replace it with something that does at least everything PA does), we should then have something pretty similar to OSX. I really wish I had the expertise in this area to help the PA, or whomever, guys...

As a proaudio user, i just find that PA is annoying and gets in the way. For me, it just makes more sense to have Jack run as the default sound server. As i said before, ALSA should be made to do the things that have made PA popular, then we would only be working with 2 audio API's - ALSA and Jack.

Hmm, so you are running the Molnar branch. Isn't that a bit overkill? It's really more designed for hard RT work. Have you tried using a preempt kernel, and tweaking the knobs? You might find that the cpu would be less loaded if it wasn't running with the overhead of the RT kernel.
If you try it, let me know how it turns out.
You can PM me (I think) on Phoronix.

It's not overkill at all. I am often running many (jack) clients, at very low latencies. PREEMPT or even a BFS kernel will work, but not as well as RT. On my hardware, if i don't use RT ~ it won't be as stable as lower latencies (ie: more likely i will get xruns). While RT comes with higher CPU load (not that much), it's much more reliable ~ and i also 'tweak the knobs' of RT. And although, i don't like the terms 'soft' and 'hard' realtime ~ proaudio falls into 'hard' realtime ~ ie: you can't have xruns, when you will be able to hear it, the behavior must be deterministic and everything must meet their deadlines. An RT kernel is up to the task, while a preempt 'might' be, but won't be able to take the same kind of stress.

cheerz

[liam]

MacOSX does provide a stable ABI for device drivers.



It shouldn't be a huge hassle to compile a custom kernel in Fedora ~ i used to do that all the time. Your standard (fedora) kernel, has a .config that already will boot on your hardware, all you have to do is use that (ie: make oldconfig), then from there, all that you would need to do is enable the RT specific stuff and go through the config (ie: make menuconfig), disabling anything you don't want (as most default kernels have a wack of drivers NOT needed). After that, it should be as simple as 'make rpm' ~ then installing the .rpms later.

As an example, i used to use Zen-kernel in Fedora (has the BFS / BFQ patches, among other really good tweaks). Look how simple the instructions are;

http://zen-kernel.org/tutorials/dist...d-installation

Kernels only suck to compile in Fedora if you strictly follow Fedora documentation (which IMO is very convoluted)...



PA may be modelled after CA in some sense, but it doesn't provide the same rich feature set. CoreAudio covers everything, it has Jack/ASIO like features, it has ALSA and PA type feature sets, handes MIDI, you can even aggregate multiple sound cards ~ all under one roof.

I'm pretty sure a lot of distro's ship with a PREEMPT kernel, just not a PREEMPT RT kernel. Fedora may not, but i am reasonably sure that Ubuntu does.



As a proaudio user, i just find that PA is annoying and gets in the way. For me, it just makes more sense to have Jack run as the default sound server. As i said before, ALSA should be made to do the things that have made PA popular, then we would only be working with 2 audio API's - ALSA and Jack.



It's not overkill at all. I am often running many (jack) clients, at very low latencies. PREEMPT or even a BFS kernel will work, but not as well as RT. On my hardware, if i don't use RT ~ it won't be as stable as lower latencies (ie: more likely i will get xruns). While RT comes with higher CPU load (not that much), it's much more reliable ~ and i also 'tweak the knobs' of RT. And although, i don't like the terms 'soft' and 'hard' realtime ~ proaudio falls into 'hard' realtime ~ ie: you can't have xruns, when you will be able to hear it, the behavior must be deterministic and everything must meet their deadlines. An RT kernel is up to the task, while a preempt 'might' be, but won't be able to take the same kind of stress.

cheerz

Well, as I said, I've yet to find a reference in the iokit docs about a stable abi (in fact, I haven't even seen the word abi used). I have found a pdf from dec. 2002 saying that there was an abi change due to moving Developer Tools from gcc 2.95 to gcc 3.1.
I've compiled kernels in the past (the best experience was using a Debian based system, IMHO), and it's the configuration that's annoying. I've no doubt I'll get around to compiling one again, but, again, it is a hassle
I had an interest in trying BFS until I read about Android's experiments where they couldn't find any data to backup Con's claims, at least as far as responsivness goes.
Regarding PA, I read that the devs recently added a shm mechanism (presumably vaguely similar to JACK). Also, PA can access multiple audio cards, since they would just each just be sinks. As for the rest of the features, they can be added. All this aside, I just got a response from Colin Guthrie and he thinks that PA has a floor of around 2ms, but that most likely better cooperation between JACK and PA is the way forward. Again, I am not averse to that, as long as it is transparent.f
ALSA is already pretty complex. Making it emcompass PA functionality seems dangerous. As I mentioned before, separation of duties is a tried and true UNIX tradition. Whether it be JACK, PA, or something else, I don't care.Just as long as ALSA keeps wraps over the hardware details.
Lastly, that's interesting about your experiences with preempt vs. RT. The reason I mentioned preempt possibly being sufficent is it the RT people seem to be attempting a hard RT path with the ability to offer microsecond level interrupts with low jitter. That level of interaction adds tons of overhead (context switching alone has got to be massive), but is great for industrial controllers. Considering the entire pipeline from user input to speakers produing sound is on the order of 60-80ms for ios, and professional users consider that good enough (though I'm guessing the latency number they maybe looking at and repoting as what they need is the time needed for an interrupt to be handled, which is, obviously, only a small part of the whole process), adding a bit of latency (say 10-12ms interrupts), shouldn't really be noticible from what I understand, and the benefit is, eventual, simplification of the audio stack.

Best/Liam

[ninez]

Well, as I said, I've yet to find a reference in the iokit docs about a stable abi (in fact, I haven't even seen the word abi used). I have found a pdf from dec. 2002 saying that there was an abi change due to moving Developer Tools from gcc 2.95 to gcc 3.1.

I'll see if i can find some documentation on it ~ as i have read about this kind of thing before, i just haven't in a long time.

I've compiled kernels in the past (the best experience was using a Debian based system, IMHO), and it's the configuration that's annoying. I've no doubt I'll get around to compiling one again, but, again, it is a hassle

My experience is the opposite. The whole custom kernel thing, i find to be pretty straight forward. by using your default .config (like make oldconfig) you will have a running kernel. by running lsmod ~ you will know what modules you need ~ then it's just a matter of disabling anything you don't want, which takes no more than a few minutes to do. But in the end, i can see what you are saying ~ Fedora is a pretty 'manual' distro, if you want a customized/specialized system.

I had an interest in trying BFS until I read about Android's experiments where they couldn't find any data to backup Con's claims, at least as far as responsivness goes.

I wouldn't put too much stock in Google/Anrdoid's experiments. BFS is hard to gauge that way (ie: benchmarking/generating data sets would be hard to do, as interactivity is hard to test). Let's put it this way - i know from my own experience's that BFS is better for the type of stuff/work loads that i use (multimedia/proaudio) than CFS (upstream). When RT was stuck at 2.6.33-rt - i actually used a BFS kernel for like a year or so (for proaduio) - it handled things much better than CFS - but you have to use 'schedtool' - specifically, the ISO_SCHED feature. At times, the difference was really noticable (like if X was using ISO_SCHED - the desktop was faster/less latency/more interactive). It was obvious in other ways too ~ with CFS i would get xruns, with BFS i wouldn't - in the exact same situation.... I'm also not sure what BFS is like on ARM ~ But on x86/x86_64 desktop/laptops, i've always had good experiences.

Regarding PA, I read that the devs recently added a shm mechanism (presumably vaguely similar to JACK). Also, PA can access multiple audio cards, since they would just each just be sinks. As for the rest of the features, they can be added. All this aside, I just got a response from Colin Guthrie and he thinks that PA has a floor of around 2ms, but that most likely better cooperation between JACK and PA is the way forward. Again, I am not averse to that, as long as it is transparent.

+1 transparency is important, which PA + jack has never really had. But on my end, i still would remove PA, as i would still want Jack to be the default sound server. Running PA on top of jack just seems like a waste to me, unless i had a very specific and equally important reason to do so (which i've never run into).

ALSA is already pretty complex. Making it emcompass PA functionality seems dangerous. As I mentioned before, separation of duties is a tried and true UNIX tradition. Whether it be JACK, PA, or something else, I don't care.Just as long as ALSA keeps wraps over the hardware details.

I don't see how that is dangerous... we aren't talking about ALSA doing this in the kernel. it would be in user-space. it essentially wouldn't be dangerous ~ because A). it's (sort of) already been done and B). Pulseaudio is already occupying the same space, allowing this functionality...as for UNIX tradition, i can agree with that, but let's not forget what sound API is commonly used on UNIX systems. OSS was not modeled with a 'separation of duties', as an example;

FreeBSD contains an independently developed implementation of the OSS API, which includes, among other things, in-kernel resampling, mixing (vchans), equalizer, surround sound, and independent volume control for each application. It also supports bit-perfect mode.

Lastly, that's interesting about your experiences with preempt vs. RT. The reason I mentioned preempt possibly being sufficent is it the RT people seem to be attempting a hard RT path with the ability to offer microsecond level interrupts with low jitter. That level of interaction adds tons of overhead (context switching alone has got to be massive), but is great for industrial controllers.

My RackmountPC is pretty much industrial, both in it's construction and how i use it. (military grade 3U rackmount case, AMD Phenom x4 965, 16gig ECC RAM, 200g SSD + 1tb SATA6g HDD, etc). I've dropped the damn thing down a flight of stairs, and turned it on a minute later to jam My system is also designed, keeping that overhead in mind. As tannenbaum has pointed out with the microkernel architecture - you will lose some performance, but it's a worthwhile sacrifice to have the added stability/reliability (or in my case, all of the 'deadlines' being met / no xruns). he speculated a 10-15% loss in performance, but went even further to say he would be okay with a 50% loss, if it meant the system would never crash. I'm not exactly sure what my overhead is, but if i had to guess maybe 5-10%, but i leave lots of overhead anyway. -> it's ultra reliable and has ON/OFF operation (loads everything i require). But when i am at home, it is setup to boot into a standard 'desktop session'.

Considering the entire pipeline from user input to speakers produing sound is on the order of 60-80ms for ios, and professional users consider that good enough (though I'm guessing the latency number they maybe looking at and repoting as what they need is the time needed for an interrupt to be handled, which is, obviously, only a small part of the whole process), adding a bit of latency (say 10-12ms interrupts), shouldn't really be noticible from what I understand, and the benefit is, eventual, simplification of the audio stack.

I can't speak for other people, but i expect no higher than 2-3ms, when playing live (keyboards, midi-controllers, live-input/mic/guitar + effects chains, etc)... ~ while on the other hand if i am mixing, then latency isn't a big deal, and <in fact> i may actually want or *require* more buffering time.. -> ie: using lots of DSP / post-processing / mastering.

cheerz

[ninez]

Well, as I said, I've yet to find a reference in the iokit docs about a stable abi (in fact, I haven't even seen the word abi used). I have found a pdf from dec. 2002 saying that there was an abi change due to moving Developer Tools from gcc 2.95 to gcc 3.1.

I Found mention of XNU kernel's stable ABI for kernel extensions, mentioned in Snow Leopard Server (google books);

Unique features of the XNU kernel

Unlike Linux, XNU offers a stable ABI for kernel extensions (kexts), allowing software extensions developed for MacOSX to continue to work across many versions of the system

found here;

http://books.google.ca/books?id=KDrU...%20ABI&f=false

Loadable kernel modules - in Wikipedia also makes note of Apple's stable ABI;

http://en.wikipedia.org/wiki/Loadable_kernel_module

Binary compatibility

Linux does not provide a stable API or ABI for kernel modules. This means that there are differences in internal structure and function between different kernel versions, which can cause compatibility problems. In an attempt to combat those problems, symbol versioning data is placed within the .modinfo section of loadable ELF modules. This versioning information can be compared with that of the running kernel before loading a module; if the versions are incompatible, the module will not be loaded.

Other operating systems, such as Solaris, FreeBSD, Mac OS X, and Windows keep the kernel API and ABI relatively stable, thus avoiding this problem. For example, FreeBSD kernel modules compiled against kernel version 6.0 will work without recompilation on any other FreeBSD 6.x version, e.g. 6.4. However, they are not compatible with other major versions and must be recompiled for use with FreeBSD 7.x, as API and ABI compatibility is maintained only within a branch.

There is also numerous places throughout Apple's developer portal / documentation where they discuss binary compatibility and how they address these kinds of problems. Have a look through i/o kit's documentation;

https://developer.apple.com/library/...00695-BAJIBFDE

Binary Compatibility

Something that has long plagued C++ library developers is the fragile base class problem. The libkern library and, more specifically, the OSMetaClass class offer ways to avoid the danger to backward binary compatibility posed by fragile base classes. But before you learn about those APIs, you might find a summary of the fragile base class problem helpful.

Note: Also see the section “Allocating Objects Dynamically” for a discussion of the use of the OSTypeAlloc macro as a factor in binary compatibility.

The Fragile Base Class Problem

The fragile base class problem affects only non-leaf classes, and then only when those classes are defined in different KEXTs. So if you never intend your libkern or I/O Kit class to be a base class, then fragile base classes won’t be an issue (and you have no need to read further). But if your class could be a base class to some other class, and you later change your class in certain ways, all external KEXTs with dependencies on your class are likely to experience problems that will cause them to break.

There's also this interesting (slightly off-topic but related) paper on L4/Darwin that may be of interest to you, Liam. (i haven't had time to read it, only a quick scan);

https://docs.google.com/viewer?a=v&q...riQQvA4D9j0ToQ

cheerz