(old)Puppy Linux Discussion Forum

Was wondering if Barry K has thought about knocking up a couple of realtime Puppies to try out?

Don't know how easy or difficult this is, but was thinking it could be an interesting little fork of Puppy, rather like the Raspberry experiments.

1.Are there any downsides to a rt kernel (apart from battery consumption on a laptop possibly)?

2.And what are the upsides to a realtime kernel? (apart from getting lower latency when you're twanging on your geetar).

Slacko, Precise, maybe as these seem to be the most popular?

Tried lowtechs excellent Studio Pups, but it would be nice just to have a basic Puppy (even a barebones) that could be experimented with.

I noticed tiny core and quite a few others have these rt versions, and it would be good if puppy also had an rt distro.

This is just a suggestion, possibly there is not much call for or interest in a RT Puppy.

Still loving the Playdayz Slacko 26.33.7, but trying out Precise 5.4 at the moment and is looking good.

Not sure what the advantages are of all the new distros though, maybe the newer kernels are more efficient/ have more drivers?

from what I understand a lot of the rt kernel has been incorporated into the mainstream kernel.

However, progress continues on the rt project see
https://rt.wiki.kernel.org/index.php/Main_Page

---

with regards to Puppy a wonder if woof would allow you to incorporate a the rt kernel patches?

or maybe this guide about switching the kernel is a possible avenue, though you may have to compile the kernel files-
http://www.murga-linux.com/puppy/viewtopic.php?t=60180

Hi Darkcity, hope you are well!

Yes I partly remember that a lot of stuff has been done in the standard kernel, but you always wonder if something's missing lol.
And without testing it you can't tell.

I spent a whole Saturday morning switching that kernel stuff and ended up with kernel panics and things, and I followed the instructions and alternative methods. To the letter. I will leave it to the experts.

I cleared my drive which was littered with gigs of Puppy Frankenstein experiments, and just saved off the good stuff, Pemasu, Micko01, Puppy Studio, Playdayz, and Barry K standard Puppy. Three or five Puppies is enough!

I ditched the Radeon box and dragged out the standard Intel graphics and dual core and everything works out of box now.

There's only so many dogs you can look after ; -)

RTPL (Realtime Puppy Linux)
Sounds interesting no doubt, perhaps have that incorporate a few other aspects floating around the forum for a rock-solid puppy, and we could have something to use in systems which need real-time capabilities.

Perhaps someone crazier than us will attempt at this again. Then again I'm probably crazy enough to try it out. Would make a neat puplet to say the least.

A CentOS-based Puppy with a realtime kernel could be awesome. Woof is already able to process Mageia's RPM packages, so I think it won't be very hard.

Iguleder wrote:A CentOS-based Puppy with a realtime kernel could be awesome. Woof is already able to process Mageia's RPM packages, so I think it won't be very hard.

Woof on a distro with a realtime kernel. I like it.
This could be neat to try out.

Smithy wrote:Hi Darkcity, hope you are well!

Yes I partly remember that a lot of stuff has been done in the standard kernel, but you always wonder if something's missing lol.
And without testing it you can't tell.

I spent a whole Saturday morning switching that kernel stuff and ended up with kernel panics and things, and I followed the instructions and alternative methods. To the letter. I will leave it to the experts.

I cleared my drive which was littered with gigs of Puppy Frankenstein experiments, and just saved off the good stuff, Pemasu, Micko01, Puppy Studio, Playdayz, and Barry K standard Puppy. Three or five Puppies is enough!

I ditched the Radeon box and dragged out the standard Intel graphics and dual core and everything works out of box now.

Actually, PuppyStudio 3.3 has a version with an RT kernel in it. All we would need to do is perhaps inject it's parts into a new pup, and see if it works. Then we can have a prototype to release, and test. If it works well enough, It could even make a 001 Release.

RTPL is Go! I might make a topic in the puplet section, and begin my work.

There is an RT kernel in Fatdog's repo. Get Fatdog, then install the RT kernel from package manager, and update your boot loader. That's all.

1.Are there any downsides to a rt kernel (apart from battery consumption on a laptop possibly)?

Less stable, and if you don't manage your resources carefully, it is easy to get a lockup (especially when you run as root whose resource allocation is "unlimited").

2.And what are the upsides to a realtime kernel? (apart from getting lower latency when you're twanging on your geetar).

Lower latency Okay, lower latency also translates to "responsiveness" - but only if you configure your system carefully (not enough just by installing the rt kernel). And there are other ways to get responsiveness, e.g. using BFS kernel.

For low latency you need to consider which programs you want to have priority. For example, if you are recording sound you want to give the recording program priority over other processes running in the background. Jack can help with this, as can using a low nice-
http://murga-linux.com/puppy/viewtopic.php?t=78256

Personally, I'm thinking about what would really need realtime, perhaps more than audio work and the like. I'm kinda thinking of installing some packages people have made for multiuser puppies, since that could potentially solve a part of that problem, or find a way to run some applications at a low access level.

That would be a Brain F***k Scheduler kernel James Bond?

After another extensive series of puppy testing sessions, I have come to the conclusion that none of these nice settings, altering things etc, gives any appreciable latency improvements over standard slacko 26.33.7.


5ms over usb is the best I am going to get I reckon. And that's fine.
Puppy Studio will do 2.6ms, but if you have a lot of tracks running, it has to be backed off somewhat.

Anyone think that some of this stuff is like snake oil and searching for the holy grail?

RTPL is Go!
Good luck with your project NeroVance! Announcer kindly did a realtime wine
pet so that could go in it as well. It's in multimedia pets.

Hi Smithy

That's interesting that you aren't seeing any improvement over the fairly old 2.6.33.7. kernel.

I would be interesting in seeing a summary of your result and what methods you used, if possible?

Hi darkcity.
Well, basically I recreated the work I had done in music2go and applied it to each distro I tested.

Burnt each puppy iso to a rewritable, let it boot, configured the same hardware card, Midi cable, software, jack, wine, wineasio etc and used the same music track as a constant. (Electro, which I put in music2go).

The track itself used nine instances of Synth1, and I opened up the audio inputs on one track to let a guitar through to jam to the tracks in realtime, (to see if any glitches were occuring while the song was playing).
Latency drops to 8 msecs throughput on the audio input for some reason, just about bearable.

Interestingly, I found no significant latency improvements on using native apps like Ardour and Qtractor, but only what I could test. If it starts getting too geeky I lose the plot

Ardour (2) doesn’t do midi, and I think there are limitations with what you can do via Nokia QT, which introduces its own latency problems.
Info via Qtractor forum.

So I stuck with wine, ‘cos it’s quite amazing except maybe the video performance could be a bit laggy possibly, especially if you add a LOAD of tracks.
And Podium does MIDI, audio and you can see latency figures underneath each volume fader. And it doesn’t crash! So it was a good solid contant to test the distros I went through.

And not quite sure about why the Jack interface looks "shinier" in Three Headed Dog than a lot of other distros. That's cosmetic, but it does, it looks "blockier" in a lot of other distros. Noticed that for a long time.
Doesn't affect the function though.

Curiously, though I found that while setting 128 periods/frames caused no xruns when the song was running, the Podium DAW says it is 256 periods/frames on each volume slider, don’t know why.

So 128 seems optimum to get a fair few tracks going without xruns, or at least with my tests.

Did a couple of screenies to show what’s going on.
http://smokey01.com/Smithy/Latency%20Test%201.png
http://smokey01.com/Smithy/Latency%20Test%202.png

Thanks for the great post. I'm currently looking at archpup, which can use archlinux's repositories. Going to be checking Audacity and Qtractor on there, maybe make an audio SFS for it. I think it makes more sense to focus on the little Puppy apps that make up for not having a full Desktop Environment, rather than get bogged down trying to compile lots of apps.

I can't find the post about Qt and Latency, I'd be greatful if you could post the link.

---
-background info on Qt-

Qt is kind of a project on its own. Nokia owned it for four years (2008-12), the trademark is now owned Digia who have started to run the project under open governance. The project started in 1991. Usually programs are written in C++, compared to Gtk where programs are commonly written C. Qt is also what the KDE project is based on.
http://en.wikipedia.org/wiki/Qt_%28framework%29

Glad if it helps towards puppy in the audio department..

The Qtractor post I found a while back was:

Qtractor graphics becomes very slow with many items

http://www.rncbc.org/drupal/node/441


It's certainly going to cause problems I would say unless you're just recording a few tracks maybe.
Re reading, it seems that rncbc can improve it with pixmap image caching, so all is not lost.
I guess that means having images in ram, so that would fit in with puppy ethos, and keep it snappy.
So not strictly audio latency related, but relevant.

Archpup, a lot of people seem to like it.

Quote "rather than get bogged down trying to compile lots of apps."

I agree, even though I don't compile, I should imagine it can get pretty frustrating if you're trying to trace problems.

Great thanks ; -)
In theory compiling is easy, but there's always one or two gotchas!