Thread has been busy - didn't see all these updates til the other day.

@Mark Van de Pas, your post about improvements is appreciated and thoughtful. Regarding Tiny Core Linux, I haven't checked it out. Not that I'm opposed to it and similar Linux variants, but when I originally looked for distributions to optimize Puppy Linux was the one that hit all the right notes:

Read only file system that's fairly transparent to users

Lots of remastering/building tools allowing contributors to spin their own variants (with an active community supporting this)

Minimal OS footprint to start with

Minimal X GUI for users averse to the CLI

There are a variety of other distributions that perform better at various pieces of this puzzle, and Tiny Core definitely hits all the right notes on the minimal part, but I'm not sure how well it meets the other requirements. And because it starts from a completely different premise it's hard to know which parts of it's configuration would be worth translating over to Puppy.

@Dynobot, wlowes - regarding nice in the mpd startup script, I see now I forgot to add a dash in front of the 15 in the init file, but is there a specific reason to choose -1 vs. -15 or higher?

About ulimit - this one is pretty interesting, and one I hadn't read about before. This seems like it should be straightforward to add to rc.local or a similar location.

Regarding the startup scripts in /etc/init.d - I'd like to point out that most of those are disabled by default - Puppy linux only starts init scripts which are marked executable, and most are not marked that way. Any that you do want to disable you can just run chmod -x instead of deleting them.

Regarding the various processes to kill, I'd like to understand what causes them to be started in the first place rather than just kill them after the fact - anything swap related can definitely go (problem is I don't know what starts it). udev related processes probably need to stay, but can be reniced. Avahi-daemon is included quite intentionally for user friendliness (and was compiled for bare minimum footprint), but also can be reniced.

@everyone else providing info on processes to renice - all the tips are appreciated and will be noted. I'm thinking of an init script which will re-nice a laundry list of processes after everything has been started.

@supersurfer, thanks for the update regarding mPad, I'll have to see if I can fix my own albums by fixing the tags.Last edited by ldolse on Wed 03 Jul 2013, 10:25; edited 2 times in total

I trired putting the ulimit command inside every place I could imagine. But non of them 'seemed' to work. I say seemed because when I change the ulimit via a shell and do a ulimit -a to see the change it shows....however if I close the shell, then reopen and do a ulimit -a the default values show up.

Also I did install util-Linux and was able to set cpu affinity.

As far as the init files I agree the best way is not to delete them but to do a -x, or even better open X and use PuppyLinux's own tools to configure which processes in the init file will be executed.

I installed a fresh copy on MPDPup and tried to do things cleaner and tested the 'tweaks' with more of a methodological approach. One at a time instead of on top of one another and adjusted nice values and listened for a change. To be honest most changes are barely noticeable if at all...

I too have been reading and experimenting where to put ulimit command at startup.

I tried at the end of my startup script which is last in the init.d list. No luck.
Then I tried in the 20.mpd startup right after the renice. Also no luck.

The thing that surprises me most is I leave my system on 7x24. Every evening when I come to listen, ulimit -s & -l are back to the default. I set them to unlimited and the next day they are back to the default.

I can't imagine I get a power failure everyday. Is it possible that logging on to root via ssh or connecting to mpd via a client somehow involkes a script that sets the default?

As a sidenote, since I'm tinkering with various music "appliances", I wondered if it would be possible to compile any kind of squeezebox server, either for mpdPup or any other Puppy variant?
I checked, and there were several questions over the past few years, but it seems no one was able to compile it for Puppy (Perl issues?).

I also saw that Idolse once asked about it in another part of the forum a couple of years back, so I wondered if anything came of it?

I know I can run squeezebox server under some other linux variants, but I would much prefer to use any puppy variant for such a server.

I tried the squeezelite player (http://code.google.com/p/squeezelite/) in mpdpup, and it runs without problems It appears as another player in the squeeze network, and I can direct my music to it from the main squeezebox server. So, the player works

However, the server is another issue....

Could it be compiled for Puppy at all (this exceeds my abilities, though...)?

Sorry for the digression, this does not relate directly to mpdPup, but since we're already tinkering with music hardware/software, I thought I might as well ask here

I too have been reading and experimenting where to put ulimit command at startup.

I tried at the end of my startup script which is last in the init.d list. No luck.
Then I tried in the 20.mpd startup right after the renice. Also no luck.

The thing that surprises me most is I leave my system on 7x24. Every evening when I come to listen, ulimit -s & -l are back to the default. I set them to unlimited and the next day they are back to the default.

I can't imagine I get a power failure everyday. Is it possible that logging on to root via ssh or connecting to mpd via a client somehow involkes a script that sets the default?

ulimit xxx has effect only on the current login session and for the logged user. That is why it is reseted every time you ssh.
I can't imagine any positive impact on sound unless you ssh under the user executing mpd.

To make these changes apply on boot and for all users or a specific user you shoul use:
/etc/security/limits.conf

StudioPuppy has a real time kernel but only supports an old version of MPD 15.4

Puppy Linux be default only has one user...root.

Every shell is started by root and PuppyLinux does not have a security/limits.conf file nor a security directory in /etc. For this reason the only way to change limts is via shell or by finding the file that invokes the limits in the first place.

The Realtime kernel has benefits of lower latency [however widely disputed as being for record only]. However the realtime kernel allows scheduling and FIFO preferences that the normal kernel does not.

Ideally repositories would be up to date with the latest versions of products and dependencies will be kept up to date and available as well. I think Idolse went through a monumental effort to get MPDPup up to the level its currently all things considered. Installing even rev 16.x of MPD on a normal distro of Puppy Linux is all but impossible for the avg user.

What about uname -a? That is it give any clue if it is a preempt kernel?

Dynobot wrote:

StudioPuppy has a real time kernel but only supports an old version of MPD 15.4

How is it?

Dynobot wrote:

Puppy Linux be default only has one user...root.
Every shell is started by root and PuppyLinux does not have a security/limits.conf file nor a security directory in /etc. For this reason the only way to change limts is via shell or by finding the file that invokes the limits in the first place.

Ok. Did I a quick search and all that seems to be related. Only one user. Looks like it is the reason pam is not installed by default.
Can you confirm that there is not any /etc/pam or /etc/pam.d directories? If this is the case is it installable via repositories?
Which is the user running mpd, root?

Dynobot wrote:

The Realtime kernel has benefits of lower latency [however widely disputed as being for record only]. However the realtime kernel allows scheduling and FIFO preferences that the normal kernel does not.

Scheduling and FIFO are actually possible with any preempt kernel.
RT kernel only adds true real time preemption for all the kernel, that is even lower latency.
Here are interesting links:
https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch
https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html
http://www.artist-embedded.org/docs/Events/2009/OSPERT/OSPERT09-Henriques.pdf

Ideally repositories would be up to date with the latest versions of products and dependencies will be kept up to date and available as well. I think Idolse went through a monumental effort to get MPDPup up to the level its currently all things considered. Installing even rev 16.x of MPD on a normal distro of Puppy Linux is all but impossible for the avg user.

The first time I tried mpdPup I was very surprised with its sound quality and praised ldolse. The main and only reason I moved away from mpdPup was the lack of support for nfs (I don't have cifs anymore).
I greatly appreciate his effort, that is why I regularly keep an eye on this thread.

Dynobot, not sure if there was some misunderstanding in my last post. I hope no, I am just trying to help

With regards to studio4 and MPD ver 15.4. To my ears it sounds just a tad bit thick compared to MpdPup. I tried installing newer versions to no avail.

Linux has a way of sucking you in....in that you start out with a seemingly simple task and 12 hours later you are still at square one. As frustration builds you [..I...] tend to become more determined and exhaust all resources along with myself in the process.

Regarding the discussion on ulimit - this is starting to sound like a major research project, I'll see what I can find out though - wouldn't be surprised if the defaults are set at compile time for the kernel. I'm pretty sure I don't want to install PAM or any extra background processes to make limits.conf work.

@DenisP - compiling Squeeze Server is possible and I've done it successfully while exploring how to package it. The real problem is the packaging - it relies heavily on Perl and numerous CPAN packages. Trying to package dozens of Perl dependencies together is a nightmare for which I've found no solution.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum