Running modern Puppy in Low RAM systems
Posted: Tue Jul 28, 2020 12:41 pm
The following is a copy of a post by Jamesbond on the old Forum which foxpup tracked down in google webcache. I understand that eventually webcache will be updated to only show the old forum current content "that it is in maintenance mode". I though jamesbond's advice was too important to loose. Thanks jamesbond and foxpup.
Puppy has grown in size in recent years. Questions have been asked, how does this size growth affect the ability of Puppy to run on older computers. To answer that questions, I have performed a test to run modern Puppy on low RAM systems.
Running modern Puppy in Low RAM systems
---
1. Tested: Dpup Stretch 7.5 CE (RC-4) with k4.1.48-i686-pae kernel (341MB)
2. Test environment: Qemu 3.1 (note1)
3. Simulated environment: RAM 256MB, Harddisk 512MB (note4)
Steps:
---
1. Get the it from here http://murga-linux.com/puppy/viewtopic.php?t=112125
2. Boot with pfix=nocopy (note2)
3. Boot with default video. Once inside, click "OK" to close the First Run wizard. Then click "OK" to close the Welcome message.
4. At this stage if you open terminal and run "free -h" you well see that only 61M is being used.
5. Run gparted and partition the harddisk to 2 partitions: 256MB for swap and 256MB for ext4. Then I mounted the swap using "swapon /dev/sda1".
6. I can comfortably run libreoffice and edit some of the reference documents I found from the ISO. However, I decided to save the session into a savefolder first.
7. During shutdown I was asked if I want to copy the SFS files to the disk, which I rejected (note3).
8. After I've rebooted, swap is automatically recognised, and the savefolder loaded. RAM usage still hovers around 60MB, no swap usage.
9. I launched web browser. The browser is already installed, I don't have to download first. The browser is Pale Moon. I visited youtube.com and watch a few trailers, in full screen, with sound, comfortably. The swap isn't even fully occupied (only about 128MB out of 256MB).
10. Web browsers are among the memory hog these days, so I'm quite confident that if I can run the web browsers with full screen video, most other every task will be fine too.
11. This is not to say I don't feel the memory pressure. I can definitely feel the swapping effect. The machine isn't as responsive, mouse clicks to start/stop video play back takes a while to respond, and pressing Esc to return from full screen also takes a few seconds to take effect. But the video playback itself is smooth, almost uninterrupted. Overall the impact is very minimal.
12. Of course, don't expect to do video editing on it. And don't expect to be able to open too many apps at the same time. But, for example, typing a document in Libreoffice and having the browser open for researching stuff at the same, is very workable. In fact I'm tying this in geany with web browser open in inside Dpup itself.
Notes:
---
1. The computer I used to run qemu (the "host" computer) is a 2012 i5 computer with 8GB of RAM. It is a 7-year old second-hand computer that I've got from gumtree. It's not exactly new.
2. Use pfix=nocopy if your RAM size is larger than the ISO, to tell Puppy __not__ to load its SFS into RAM (for RAM size smaller than ISO this is automatic). This way, you can use your RAM for its intended purpose - running applications.
3. I decided not to copy the SFS from the (simulated) CD ROM to the (simulated) harddisk because in Qemu both have the same access speed, and because I have only set up a 512MB disk. In real machines you may want to copy it especially if you have the space because generally harddisk is a lot faster than a CD.
4. Use a real harddisk. Don't use USB flash drive, SD card, of the likes. These flash memory devices (with exception of SSD) are __really slow__ devices. With low-RAM systems you definitely want to use swap, and you want to use the fastest device you have for it. If you have both USB flash drive and harddisk, and have to choose which one to use, do it this way: use your USB flash drive for savefile/savefolder, and use your harddisk for swap.
5. Why dpup-stretch?
- It's 341MB - a bit on the bigger side as far as Pup is concerned.
- It's very recent (Jan 2019 release).
- It's 32-bit.
6. I did similar test for Fatdog64. I couldn't get it to run comfortably with 256MB, but at 384MB I got more or less the same experience. See link here: http://murga-linux.com/puppy/viewtopic. ... 72#1020472
7. Finally: in case you forget, this is a simulated test done in Qemu. I don't have a machine with 256MB or 384MB RAM anymore. The performance I've gotten from Qemu is very likely to be better than performance in real low RAM machines (since, not only they are low RAM, but also has older CPU, which is also slower), so take them with a grain of salt. The point still stands, however, that even modern Puppy can still be used on low RAM machines, even if they do look bigger than before.
---
Two last words:
- This kind of test probably needs to be done every couple of years to confirm its validity
- Dpup Stretch is a nice looking polished Puppy that I won't mind using on my older 32-bit only computers.
____________________________________________
EDIT: I also tested Upup Bionic Beaver
from here: http://murga-linux.com/puppy/viewtopic.php?t=113244 which according to the post date is also dated Jan 2019. This is 260MB in size, and is also meant for 32-bit systems. The office suite is abirword+gnumeric (vs Libreoffice for Dpup Stretch); it's browser is Light (a derivative of Mozilla) (vs Palemoon in Dpup Stretch).
I used the same configuration and the same virtual disk - same swap file and sharing the same partition for its savefolder (but different savefolder for each).
All the previous notes applies, except for one thing: while I could get the same response generally for non-browser applications, once I start the Light browser the system becomes sluggish. This is because Light uses a lot more memory than Palemoon (as htop indicates). The system becomes sluggish due to swapping especially when playing video (I used the same youtube video). When I adjusted RAM up to 384MB, then everything becomes reasonably responsive again.
I'm typing this EDIT from UpupBB itself.
_________________________________________
EDIT: Updated Nov 2019. Running Dpup Stretch in 14-year laptop.
I finally got the chance to test this on a real machine.
I got a Dell laptop, circa 2005. It has Pentium M CPU with Centrino chipset that can run between 800Mhz and 1.6GHz, with 512MB RAM and 60GB harddisk.
I use the same Dpup Stretch (but I used the Jul 2019 version). I used the legacy version with 4.1 kernel without PAE (all PAE does in 512MB machine is to eat memory and makes it run hotter).
I installed it manually on a USB stick with fat32 partition (factory default - never formatted to anything else); so the harddisk is not used at all.
Puppy boots up well. Initially it booted very slow because the CPU is fixed to 800MHz by BIOS; but once I "override" it; running it at variable frequency up to 1.6GHz is very comfortable.
Because the RAM size is only 512MB, puppy decides to use pfix=nocopy by default. Booting with no savefile uses up only about ~63MB (this is with the welcome dialog shown).
I created a 1GB savefile, and booting with this savefile, RAM used is only about ~61MB (probably because the welcome screen isn't running anymore rather than anything to do with the savefile itself).
Browsing using palemoon works, watching youtube (even fullscreen) works comfortably, with plenty of RAM left (only about ~200MB were used for watching full-screen video in a single tab). I don't even use a swap file.
I wanted to try the libreoffice but it did not work for two reasons:
a) the getlibre script has a bug; it assembles the files in the save device; but of course assembling only works if the save device has a Linux filesystem, of which fat32 isn't.
b) even if it were not because of the bug, the assembling would fail because this particular laptop has an overheating issue: the "mksquashfs" to create the libreoffice would have caused thermal shutdown before the sfs is completely created (see below for the reason).
So I cannot test that. However, this demonstrates that the result is quite consistent with the test results I've done in qemu, previously.
=====================
Notes:
1. The laptop I used for testing is from 2005 (from BIOS date). At the time of writing this is 14-year laptop, and even on its heyday, this wouldn't be considered as a high-end laptop. Running a Puppy created in 2019 on a machine from 2005 and can still have it running very well is pretty amazing in my book.
2. Almost everything works: screen works (xorg automatic) booting up to highest resolution (1650x1050), touchpad works, sound works, wireless works. I plugged in a logitech mouse and of course it works as well.
3. The only thing that DOES NOT work and makes Puppy unusable on this machine is because it cannot make the CPU fan to work. This is apparently a well-known issue; plenty of articles from days past to fix this "problem" (from 2.6.xx kernel days); but time has moved on and whatever solutions that I can still find on the Internet, no longer helps. The fan itself definitely works, if I boot it to WinXP then it runs. It only refuses to run under Puppy.
If I really want to get Puppy to work on it, it's easy: just open the case, cut the cable to the CPU fan, and re-attach it to a 5V (or 12V) rail and let the fan run at full-speed. But since I only use it for this particular testing, and my son want to keep the XP for playing legacy games (Win 3.1 games that can't run on Wine), so I leave it as is.
After note:
===========
Well, that concludes my experiment. My conclusion is that a modern Puppy can still comfortably run on a medium spec 14-year laptop comfortably.
You may disagree with me on the conclusion. But here is the thing. Let's compare the same situation to 10 year ago: trying to run a 2008 Puppy on a ten-year-older machine (that is, 1998 machine). I actually did that: back in 2008, I tried to run Puppy 3.0 on a desktop with a Pentium CPU (can't remember the speed, perhaps 133MHz or something), with 64MB RAM and perhaps 40GB disk (which previously ran Windows 95). It did __not__ work. Even with 64MB swap enabled, Puppy was way __too slow__ to be useful for anything. Puppy 2.x fared a bit better (=better, not definitely not great), but Puppy 2.x was getting long in the tooth by then, and I wanted the latest and greatest.
So? Ten years ago, the latest and greatest Puppy did not work on a ten-year-old machine.
Today, the latest and greatest Puppy runs very well on a 14-year old machine.
I would say that despite Puppy's getting fatter, not only Puppy retains its ability to run on older machines; it actually __improves__ the situation, a lot! All thanks to the hard work of the people (visible and invisible) who keep improving it.
Of course, if you insist on running modern Puppy on 128MB machine (which is 20-year old by now), you are probably asking a bit too much. If you really need that then you shoud stick to older Puppies. I would say that at 64MB, you'd probably be better off using Win98SE because even older Puppy would struggle.
Puppy has grown in size in recent years. Questions have been asked, how does this size growth affect the ability of Puppy to run on older computers. To answer that questions, I have performed a test to run modern Puppy on low RAM systems.
Running modern Puppy in Low RAM systems
---
1. Tested: Dpup Stretch 7.5 CE (RC-4) with k4.1.48-i686-pae kernel (341MB)
2. Test environment: Qemu 3.1 (note1)
3. Simulated environment: RAM 256MB, Harddisk 512MB (note4)
Steps:
---
1. Get the it from here http://murga-linux.com/puppy/viewtopic.php?t=112125
2. Boot with pfix=nocopy (note2)
3. Boot with default video. Once inside, click "OK" to close the First Run wizard. Then click "OK" to close the Welcome message.
4. At this stage if you open terminal and run "free -h" you well see that only 61M is being used.
5. Run gparted and partition the harddisk to 2 partitions: 256MB for swap and 256MB for ext4. Then I mounted the swap using "swapon /dev/sda1".
6. I can comfortably run libreoffice and edit some of the reference documents I found from the ISO. However, I decided to save the session into a savefolder first.
7. During shutdown I was asked if I want to copy the SFS files to the disk, which I rejected (note3).
8. After I've rebooted, swap is automatically recognised, and the savefolder loaded. RAM usage still hovers around 60MB, no swap usage.
9. I launched web browser. The browser is already installed, I don't have to download first. The browser is Pale Moon. I visited youtube.com and watch a few trailers, in full screen, with sound, comfortably. The swap isn't even fully occupied (only about 128MB out of 256MB).
10. Web browsers are among the memory hog these days, so I'm quite confident that if I can run the web browsers with full screen video, most other every task will be fine too.
11. This is not to say I don't feel the memory pressure. I can definitely feel the swapping effect. The machine isn't as responsive, mouse clicks to start/stop video play back takes a while to respond, and pressing Esc to return from full screen also takes a few seconds to take effect. But the video playback itself is smooth, almost uninterrupted. Overall the impact is very minimal.
12. Of course, don't expect to do video editing on it. And don't expect to be able to open too many apps at the same time. But, for example, typing a document in Libreoffice and having the browser open for researching stuff at the same, is very workable. In fact I'm tying this in geany with web browser open in inside Dpup itself.
Notes:
---
1. The computer I used to run qemu (the "host" computer) is a 2012 i5 computer with 8GB of RAM. It is a 7-year old second-hand computer that I've got from gumtree. It's not exactly new.
2. Use pfix=nocopy if your RAM size is larger than the ISO, to tell Puppy __not__ to load its SFS into RAM (for RAM size smaller than ISO this is automatic). This way, you can use your RAM for its intended purpose - running applications.
3. I decided not to copy the SFS from the (simulated) CD ROM to the (simulated) harddisk because in Qemu both have the same access speed, and because I have only set up a 512MB disk. In real machines you may want to copy it especially if you have the space because generally harddisk is a lot faster than a CD.
4. Use a real harddisk. Don't use USB flash drive, SD card, of the likes. These flash memory devices (with exception of SSD) are __really slow__ devices. With low-RAM systems you definitely want to use swap, and you want to use the fastest device you have for it. If you have both USB flash drive and harddisk, and have to choose which one to use, do it this way: use your USB flash drive for savefile/savefolder, and use your harddisk for swap.
5. Why dpup-stretch?
- It's 341MB - a bit on the bigger side as far as Pup is concerned.
- It's very recent (Jan 2019 release).
- It's 32-bit.
6. I did similar test for Fatdog64. I couldn't get it to run comfortably with 256MB, but at 384MB I got more or less the same experience. See link here: http://murga-linux.com/puppy/viewtopic. ... 72#1020472
7. Finally: in case you forget, this is a simulated test done in Qemu. I don't have a machine with 256MB or 384MB RAM anymore. The performance I've gotten from Qemu is very likely to be better than performance in real low RAM machines (since, not only they are low RAM, but also has older CPU, which is also slower), so take them with a grain of salt. The point still stands, however, that even modern Puppy can still be used on low RAM machines, even if they do look bigger than before.
---
Two last words:
- This kind of test probably needs to be done every couple of years to confirm its validity
- Dpup Stretch is a nice looking polished Puppy that I won't mind using on my older 32-bit only computers.
____________________________________________
EDIT: I also tested Upup Bionic Beaver
from here: http://murga-linux.com/puppy/viewtopic.php?t=113244 which according to the post date is also dated Jan 2019. This is 260MB in size, and is also meant for 32-bit systems. The office suite is abirword+gnumeric (vs Libreoffice for Dpup Stretch); it's browser is Light (a derivative of Mozilla) (vs Palemoon in Dpup Stretch).
I used the same configuration and the same virtual disk - same swap file and sharing the same partition for its savefolder (but different savefolder for each).
All the previous notes applies, except for one thing: while I could get the same response generally for non-browser applications, once I start the Light browser the system becomes sluggish. This is because Light uses a lot more memory than Palemoon (as htop indicates). The system becomes sluggish due to swapping especially when playing video (I used the same youtube video). When I adjusted RAM up to 384MB, then everything becomes reasonably responsive again.
I'm typing this EDIT from UpupBB itself.
_________________________________________
EDIT: Updated Nov 2019. Running Dpup Stretch in 14-year laptop.
I finally got the chance to test this on a real machine.
I got a Dell laptop, circa 2005. It has Pentium M CPU with Centrino chipset that can run between 800Mhz and 1.6GHz, with 512MB RAM and 60GB harddisk.
I use the same Dpup Stretch (but I used the Jul 2019 version). I used the legacy version with 4.1 kernel without PAE (all PAE does in 512MB machine is to eat memory and makes it run hotter).
I installed it manually on a USB stick with fat32 partition (factory default - never formatted to anything else); so the harddisk is not used at all.
Puppy boots up well. Initially it booted very slow because the CPU is fixed to 800MHz by BIOS; but once I "override" it; running it at variable frequency up to 1.6GHz is very comfortable.
Because the RAM size is only 512MB, puppy decides to use pfix=nocopy by default. Booting with no savefile uses up only about ~63MB (this is with the welcome dialog shown).
I created a 1GB savefile, and booting with this savefile, RAM used is only about ~61MB (probably because the welcome screen isn't running anymore rather than anything to do with the savefile itself).
Browsing using palemoon works, watching youtube (even fullscreen) works comfortably, with plenty of RAM left (only about ~200MB were used for watching full-screen video in a single tab). I don't even use a swap file.
I wanted to try the libreoffice but it did not work for two reasons:
a) the getlibre script has a bug; it assembles the files in the save device; but of course assembling only works if the save device has a Linux filesystem, of which fat32 isn't.
b) even if it were not because of the bug, the assembling would fail because this particular laptop has an overheating issue: the "mksquashfs" to create the libreoffice would have caused thermal shutdown before the sfs is completely created (see below for the reason).
So I cannot test that. However, this demonstrates that the result is quite consistent with the test results I've done in qemu, previously.
=====================
Notes:
1. The laptop I used for testing is from 2005 (from BIOS date). At the time of writing this is 14-year laptop, and even on its heyday, this wouldn't be considered as a high-end laptop. Running a Puppy created in 2019 on a machine from 2005 and can still have it running very well is pretty amazing in my book.
2. Almost everything works: screen works (xorg automatic) booting up to highest resolution (1650x1050), touchpad works, sound works, wireless works. I plugged in a logitech mouse and of course it works as well.
3. The only thing that DOES NOT work and makes Puppy unusable on this machine is because it cannot make the CPU fan to work. This is apparently a well-known issue; plenty of articles from days past to fix this "problem" (from 2.6.xx kernel days); but time has moved on and whatever solutions that I can still find on the Internet, no longer helps. The fan itself definitely works, if I boot it to WinXP then it runs. It only refuses to run under Puppy.
If I really want to get Puppy to work on it, it's easy: just open the case, cut the cable to the CPU fan, and re-attach it to a 5V (or 12V) rail and let the fan run at full-speed. But since I only use it for this particular testing, and my son want to keep the XP for playing legacy games (Win 3.1 games that can't run on Wine), so I leave it as is.
After note:
===========
Well, that concludes my experiment. My conclusion is that a modern Puppy can still comfortably run on a medium spec 14-year laptop comfortably.
You may disagree with me on the conclusion. But here is the thing. Let's compare the same situation to 10 year ago: trying to run a 2008 Puppy on a ten-year-older machine (that is, 1998 machine). I actually did that: back in 2008, I tried to run Puppy 3.0 on a desktop with a Pentium CPU (can't remember the speed, perhaps 133MHz or something), with 64MB RAM and perhaps 40GB disk (which previously ran Windows 95). It did __not__ work. Even with 64MB swap enabled, Puppy was way __too slow__ to be useful for anything. Puppy 2.x fared a bit better (=better, not definitely not great), but Puppy 2.x was getting long in the tooth by then, and I wanted the latest and greatest.
So? Ten years ago, the latest and greatest Puppy did not work on a ten-year-old machine.
Today, the latest and greatest Puppy runs very well on a 14-year old machine.
I would say that despite Puppy's getting fatter, not only Puppy retains its ability to run on older machines; it actually __improves__ the situation, a lot! All thanks to the hard work of the people (visible and invisible) who keep improving it.
Of course, if you insist on running modern Puppy on 128MB machine (which is 20-year old by now), you are probably asking a bit too much. If you really need that then you shoud stick to older Puppies. I would say that at 64MB, you'd probably be better off using Win98SE because even older Puppy would struggle.
).
