I’ve just booted 2016-02-21 lxqt 8.3 image to get a “dpkg --get-selections >/backup/package-selections” list of what I need to install on my console 8.2 2015-11-12 image to upgrade to the current testing image without starting over.
I noticed that 2016-02-21 8.3 lxqt kernel is 4.1.x-ti-rt whereas 2015-11-12 8.2 console was 4.1.x-ti kernel.
kernel options blurb at: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#4.1.x-ti
says “it is slated to replace the v3.8.x tree in Debian Jessie, cape manager support is enabled”, why the -rt variant now?
My current project (BBW running on 2015-11-12) has pretty much zero dependence on kernel version, other than any changes in /sys/class/ directory layout, as its pure C code using a bunch of gpio pins, but I’d like to track Jessie as improvements in things like BoneScript and Node-Red would help a friend with a project – I’ve got him started with 3.8.x lxde 7.9 2015-11-12 image on a BBG, while all the “improvements” seem to be in 8.x Debian.
–wally.
I know that, I was wondering about BeagleBone specific stuff like the cape manager, BoneScript, etc. If it has all the features of 4.1.x-ti plus the rt patches without breaking anything, unless there are clear benchmarks showing -rt is inferior for some workloads, why not just consolidate. If there are, it’d be nice to have it mentioned in the blurb to help guide a choice.
As I said my current project only cares about the kernel version if it changes /sys/class/ directory layouts or names, but for some future ideas better performing Posix real-time code might be nice.
I’ll play around a bit and see if I notice anything, but I’ve got to put this aside for about a week, I wanted to ask before I put things on hold.
Its complicated but in the past I’ve had some -rt kernels show worse peak latency with real-time Posix code than without. I understand the -rt patches don’t make the kernel suitable for “hard” real-time but if I can keep the worst case latency below about 20% of my servo loop and infrequent enough, it’d work for what I’ve in mind and be way easier to deal with than Xenomi kernels.
I’ve used the old rtl-3.1 patches (I believe to 2.2.x) many years ago for a hard real-time application that ran for about 15 years in labs on all three coasts – it was basically “set and forget”, it just ran, but if I’d needed to update kernels maintenance would have been a nightmare, since it was only on an isolated network with no outside connectivity this was OK, Once I installed the boxes I never touched them again. – they just worked until retired which was most gratifying.
–wally.
With regards to any of the "v4.1.x" and 'v4.1.x+" branches,
we are keeping everything as compatible as possible.
4.1.x-ti vs 4.1.x-rt-ti is exactly the same, other then RT enablement..
The biggest issue with 4.1.x-rt-ti, some usb devices* (camera/wifi)
work "better" with the non-rt patchset.
* aka, to be known as the 'cheap' usb devices 
Regards,
Thank you! This is exactly the kind of information I was looking for.
I’ve had no success with USB webcams on my BBW and BBB, although the cameras work fine on Raspberry Pi2 and desktop Linux. I will give them a try again with the newest kernels and throw a BBG into the mix, when I return in about a week.
I think my BBB has “flaky” USB port hardware as its not even reliable picking up a mouse/keyboard on a hub, or wireless Logitech keyboard/trackpad with or without the hub, when I try to use the HDMI, so I won’t bother with trying it unless the BBW & BBG now work with the webcams. My mouse/keyboard are Logitech (hardly “cheap”), and I’ve tried two different powered hubs (again both hubs are fine with the RPi2)
–wally.