Remaster v. Puppy + savefile any speed diff?

Message

jockjunior · #1 Post by **jockjunior** » Fri 15 Oct 2010, 15:09

Sorry if this has been asked before cant seem to find it.

If I remaster Puppy 5.1.1 to include other programs and drivers I need for my system will it run faster than Puppy + the usual savefile?

Will it be loaded into ram and run from there?

Is it worth the trouble?

thanks

jock

Toshiba laptop 798meg ram

Jim1911 · #2 Post by **Jim1911** » Sun 24 Oct 2010, 23:00

Your new remastered sfs will load into ram. Your bootup will be slightly slower but the programs should run faster. I consider it worth the trouble. One advantage is that you've got your remaster as a backup of all your tweaks to your installation.

Bruce B · #3 Post by **Bruce B** » Mon 25 Oct 2010, 00:23

I think a very important and elementary understanding of our computers is: Programs run in
RAM

It doesn't matter where the programs are stored, they are copied from the storage location,
then run in RAM

If we, for example; copy Puppy's SFS file to RAM, the programs do not run in the SFS file,
they are copied out of the SFS file then run in RAM

The speed increase associated with having the SFS file in RAM is because of the reduced
read and copy time. Not only do the files not run in the SFS archive, it would be impossible
to run them in the archive if for no other reason than because they are compressed. They
need to be read from archive and decompressed into RAM, then executed in RAM space.

For my use, unless I had lots of RAM, I'd rather manage RAM resources by NOT copying
the SFS file to RAM, this giving me an extra 100MB or so RAM

~

disciple · #4 Post by **disciple** » Mon 25 Oct 2010, 05:47

So if you remaster:
1. Booting will be slightly slower
2. The added programs will start faster
3. You will have less available ram
4. Programs will not run any faster

Jasper · #5 Post by **Jasper** » Mon 25 Oct 2010, 10:00

Hi,

I am particularly interested in the question and in the answers so far; which, although enlightening, I do not fully understand and I have some supplementary questions.

One question is - if I run Lucid Puppy 5.1 from the standard live CD and then run Htop my RAM usage displays as only 40 MB, but when I remove the CD (where the sfs file is more than 120 MB) how does everything continue to work as expected?

My regards

If the answer is compression then presumably there a reason why everything was not compressed (or fully compressed) on the CD?

Bruce B · #6 Post by **Bruce B** » Tue 26 Oct 2010, 00:42

Sir Jasper wrote: I am particularly interested in the question and in the answers so far; which, although enlightening, I do not fully understand and I have some supplementary questions.

One question is - if I run Lucid Puppy 5.1 from the standard live CD and then run Htop my RAM usage displays as only 40 MB, but when I remove the CD (where the sfs file is more than 120 MB) how does everything continue to work as expected?

Using your description, lets develop a stable premise. (1) The SFS file has been copied
to RAM and is using its size in RAM which is 120MB (2) It takes other RAM resources to
run the machine which would account for the 40MB.

Htop is simply not doing all the math. I can say this with some confidence because
I've seen it myself also.

This can make it a little confusing.

But logic says: If we copy a 120MB file to RAM it's
taking up that much space in RAM, even if our utility isn't reporting it.

Htop probably reports Total RAM then subtracts used processes, cache and buffers,
then gives us the sum. The SFS doesn't fall into the categories of used processes,
cache or buffers.

The SFS is a character device setup on a block device called a loop device.

We can see the existence of the SFS file by running the mount command. It should
show up as a mounted loop device.

A problem is that even though it shows up with mount it doesn't say where it is
mounted from.

However, we can deduce that if we can remove the CD and it still works that it is NOT
mounted from the CD

Moreover, we can deduce that if we do not have the same SFS file anywhere on
other media, such as hard disk, it is not mounted from there either.

The df -h command will also tell us some, we should find a file system of the same size as the SFS

Computers are dumb. Powerful sure, but dumb. Even if the utilities we are usining are
not written to show us what we look for, we as human technicians have the inductive
and deductive reasoning capacity to fill in the blanks.

~

All of this is important to the person who wishes to tweak performance or save
resources. He needs to know what is going on with his most high speed media RAM in
order to make the best use of it, which is another subject.

DaveS · #7 Post by **DaveS** » Tue 26 Oct 2010, 05:24

Bruce... if we have a 120MB SFS file, would that not ACTUALLY take up about 400MB of ram? Would the file be uncompressed in ram?

Bruce B · #8 Post by **Bruce B** » Tue 26 Oct 2010, 05:49

DaveS wrote:Bruce... if we have a 120MB SFS file, would that not ACTUALLY take up about 400MB of ram? Would the file be uncompressed in ram?

True, the SFS is its actual size. And not decompressed, regardless of where it exists.
Moreover it is read-only.

BUT when we view the contents, it displays the actual size of the directories and files - not
lending a clue that it is compressed.

Copying files out of it automatically decompresses them.

~

DaveS · #9 Post by **DaveS** » Tue 26 Oct 2010, 06:19

Bruce B wrote:
True, the SFS is its actual size. And not decompressed, regardless of where it exists.
Moreover it is read-only.

BUT when we view the contents, it displays the actual size of the directories and files - not
lending a clue that it is compressed.

Copying files out of it automatically decompresses them.

~

Understood.. so with a frugal install, the pup.sfs file is loaded into ram, and then as we request a program, it uncompresses them for use on the fly. The save file is not loaded into ram though, so when we request a program from there, it decompresses from the HD, which is slower. However, once in use, both programs would run equally fast?
So a re-master (assuming additions not deletions) would use more ram due to a larger pup.sfs file?

Another small point: most will use a consistent save file size (250MB for me), so using say a 100MB pup.sfs plus a 250 MB save file uses 350MB disk space. With the save file used up by 100MB the disk space used remains the same, but if we remaster, which increases the size of the pup.sfs file, then create another 250MB save file, we end up using more disk space for no real world gain.

disciple · #10 Post by **disciple** » Tue 26 Oct 2010, 07:02

DaveS wrote:so with a frugal install, the pup.sfs file is loaded into ram, and then as we request a program, it uncompresses them for use on the fly.

Yes

The save file is not loaded into ram though, so when we request a program from there, it decompresses from the HD, which is slower.

No, the save file is not compressed. The program is read from the hard drive, but doesn't need to be decompressed unless it has been upxed

However, once in use, both programs would run equally fast?

Yes

So a re-master (assuming additions not deletions) would use more ram due to a larger pup.sfs file?

Yes, unless you removed more programs than you added when you remastered.

DaveS · #11 Post by **DaveS** » Tue 26 Oct 2010, 07:10

Interesting this, because of this thorny question re browsers. A browser built in to the pup.sfs file is difficult to upgrade, but loads really fast (first load of the day only), and can be better optimised for the distro, whereas a browser in the save file is much easier to upgrade, but loads slower (again, first time only). Maybe the Lucid way is better long term.....

tubby · #12 Post by **tubby** » Tue 26 Oct 2010, 07:29

As we are on the subject of save files and the relation of ram and sfs files, what is relevance of the swap file and what size should it be?.

Bruce B · #13 Post by **Bruce B** » Tue 26 Oct 2010, 08:43

DaveS wrote:Interesting this, because of this thorny question re browsers. A browser built in to the pup.sfs file is difficult to upgrade, but loads really fast (first load of the day only), and can be better optimised for the distro, whereas a browser in the save file is much easier to upgrade, but loads slower (again, first time only). Maybe the Lucid way is better long term.....

DaveS,

I won't answer your earlier post because Disciple's answer suffices.

FYI, I use Puppy 4.00 and I modify the pup_400.sfs extensively prior to use. One thing I
do is remove SeaMonkey because it is old.

I could reinstall a newer SeaMonkey and repack the pup_400.sfs. But I don't because I
don't know when the next SeaMonkey will come out.

I install SeaMonkey separately.

I could install it inside the pup_save file.

I could install it outside the pup_save file, because SeaMonkey doesn't care where it is
installed. It doesn't need a specific path and can by way of relative paths figure out
where its parts are.

I could make an sfs for it and mount it, which is normally what I do.

SeaMonkey is a huge application, so it loads slower than small apps. But only the first
time? Yes, maybe!

If so, here is why: When we close SeaMonkey, if the machine has enough RAM it
retains SeaMonkey (or a large portion of it) in RAM for the next time we run it. This
eliminates the read and copy as we had to do on the first run.

This is what caching is all about. The logic is we are creatures of habit. We tend to use
certain apps of our choice over and over. Linus' design logic is: if we have the RAM,
let's use it.

Cache can never be perfect, because the computer has no way of knowing for sure
what we will run next. But it is fairly effective to the extent that we tend to open and
close the same apps during a session.

Also, it doesn't take too much overhead to hold the apps in cache. If RAM is near full
and a new big application is opened, Linux will drop something out of cache to make
room for the new application.

Bruce

~

When cache and buffers are considered as part of Linux' operation, it should be
apparent why copying the big SFS to RAM might actually be a performance loss on a
low RAM machine.

Jasper · #14 Post by **Jasper** » Tue 26 Oct 2010, 11:07

Hi again,

Thank you very much for your lucid, detailed and helpful answers.

This misreporting of Puppy RAM usage by Htop, the Widgets RAM bar and other programs seems, to me, to be seriously misleading (and especially important for users with limited RAM).

Now that I understand, I can mentally deduct the size of my sfs file from the total RAM shown by Htop (or memorise the answer), but it would be ideal if the programs could be amended to reflect these special (unique or rare) requirements for Puppies.

My regards

disciple · #15 Post by **disciple** » Wed 27 Oct 2010, 05:23

I'm wondering, if you put a large file in /tmp (which is in ram with Puppy), does the ram usage reported by htop change?

DaveS · #16 Post by **DaveS** » Wed 27 Oct 2010, 06:13

disciple wrote:I'm wondering, if you put a large file in /tmp (which is in ram with Puppy), does the ram usage reported by htop change?

This raises an interesting question: I guess temp, although in ram, remains part of the 'save file and is therefore subject to the same physical limits, ie. one can fill it up with a big download like a movie file or office suite .pet prior to install?

disciple · #17 Post by **disciple** » Wed 27 Oct 2010, 06:35

No, it isn't in the save file. It is in ram

DaveS · #18 Post by **DaveS** » Wed 27 Oct 2010, 06:48

disciple wrote:No, it isn't in the save file. It is in ram

OK then, can you explain this: wary, frugal, HD. Watching a streaming video fills the save file! Space is recovered as soon as the stream is terminated, thus, I have had to abort watching long video as the save file got critical.
Edit: Just tested on Quirky.. same deal. Maybe a mplayer buffer setting?

Zpup · #19 Post by **Zpup** » Wed 27 Oct 2010, 07:25

ISorry, if this has been covered elsewhere

Memory, swap issue After a live cd boot seamonkey crash Puppy 4.3.1 I have 142M free, and would like to flush / reset the memory, get back 100M, i
I have 242M free ram @ first boot.

I checked for zombies, using puprocess, what's eating up the memory, ?

Dell D610, happy with the puppy experience so far, btw this machine has run mipup, lighthouse, teenpups, and i recall this has happened before on other live cds' as well

this should be easy, my guess is the virtual swap file, or tmp space in Ram is toast or reserved.

mjaksen · #20 Post by **mjaksen** » Wed 27 Oct 2010, 09:56

Sorry to belabor the beaten dead horse, but the way everyone (including me) seems so gung ho to remaster their own custom Puppy begs the question of whether it's a rather inefficient idea.

If you have enormous RAM, does it matter either way whether you remaster or create a huge save file and run everything from the save file?

If you have frugal RAM, would you be better served to just install the app as a Pet rather than create the newest ChubbyPup?

If you have small RAM, would you be better served to use a barebones type puppy and load up on the Pets in the savefile?

Q1: Does it matter if I mount all my Apps ChoicePup style vs. installing the Pets?

Q2: Does it matter if I mount a SFS ChoicePup style, or BootConfiguration style?

-Marc

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Remaster v. Puppy + savefile any speed diff?

Remaster v. Puppy + savefile any speed diff?