bottom dog - minimum requirements?

What works, and doesn't, for you. Be specific, and please include Puppy version.
Post Reply
Message
Author
kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

bottom dog - minimum requirements?

#1 Post by kethd »

What are the lowliest pups feasible? What are the outer, lower limits? What happens there? (This is not a very practical question, more theoretical, but esp applicable to old laptops.)

The Linux kernel is based on the 386 instruction set. What parts of Puppy, if any, require more than a 386 to execute?

I guess the kernel is about 1MB, and image.gz is about 7MB and unpacks to about 12MB. So, you need a way to load those two files, and probably an absolute minimum of about 16MB for Puppy to try to start, get to a text command line. At that point, you need to access usr_cram.fs, about 50MB. If you can just get it mounted and running you can have the full GUI. Maybe this is possible with less than 32MB?

If you want PUPXXX, you'll need a writable storage device with a minimum of about 5MB.

If you don't need swap, you might be better off without it. Using it might just slow things down, but might let you do bigger, more complex tasks.

Such old equipment is likely to have little or no access to CD drives. And no USB. And no PCMCIA. The most powerful general method is moving in a loaded hard drive. If this is not possible, the fall-back is to boot from floppy and load up the hard drive via the parallel port, with LapLink, Ghost, or some other way. (There are ways to attach CD drives and hard drives to a parallel port.)

What have you tried? What did or did not work for you? 386? 486?

http://puppylinux.org/wikka/MinReq
http://puppylinux.org/wikka/InstallingPuppyInMsdos

http://www.murga.org/%7Epuppy/viewtopic.php?t=1721
http://www.murga.org/%7Epuppy/viewtopic.php?t=1737
http://www.murga.org/%7Epuppy/viewtopic.php?t=1931
http://www.murga.org/%7Epuppy/viewtopic.php?t=2344

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#2 Post by kethd »

Over a broad range of computers, Puppy boots in about one minute.

====
LINLD vs. GUJIN

After spending a day testing DOS bootloaders on Puppy 1.0.7b over a broad range (P-120 to AMD Duron 1000MHz, 16MB to 256MB) the sad results are that linld is mostly better, but loses to Gujin when there is just barely enough memory (32MB).

On fast computers, linld is just slightly faster. On slower computers, linld is progressively faster than Gujin -- quite significant on slow computers.

However, with just 32MB of RAM, Gujin works and linld fails. (So I cannot recommend linld as the Puppy standard. The search for the best bootloader continues...)

With less than 32MB, they both fail. But a traditional native installation of Puppy (HDoption-2 GRUB-MBR) boots all the way to GUI on 32MB. And 24MB. And even 16MB! With 24MB and a swap drive, you could probably do almost anything, if you have enough patience. This information will be relevant to some old laptops.

Some operations are much faster if you exit Xwindows and run from a text command line.

(With the computers most people are likely to use, the biggest potential improvement would be to eliminate the time to copy usr_cram.fs to ram. If it could just be mounted and have the boot continue, while it was being transfered to cache in the background, and then locked in to cache ram whenever than transfer completes, that might be ideal...)

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

486DX2-50

#3 Post by kethd »

I have been exploring the lower pup limits, on a 486DX2-50 (25 bogomips), using 107b.

A standard (HDoption-1 IDE) pup installation is usable, with patience. With the Gujin bootloader, you can boot in just 32MB. But Gujin takes an extra minute to boot, so use LINLD if you can, if you have more than 32MB.

I think this type of pup is extra-lethargic on underpowered hosts, due to the extra work of constantly dealing with the compressed filesystems. If there is enough RAM to load usr_cram.fs completely, it might be OK. But otherwise, I think you'd get better performance with an HDoption-2 native Linux type install.

An IDE HDoption-2 install takes up about 150MB. For experimenting, you'll want to inhibit autostart of XWIN by renaming the xwin script to xwin2, so that you have to start it manually. This type of install can boot to a command line in just 8MB! With just 12MB, you can start the GUI. The more ram, the more you can do, as a practical matter. With 16MB you can use simple GUI programs without waiting too long. You'll probably want at least 32MB to use more challenging programs in the GUI.

Sometimes the graphics desktop background did start, but with a checkerboard pattern that made the icon labels very hard to read (after renaming xwin). There is a desktop menu tool that allows setting a solid background -- which seems to boot up faster than a graphic background.

I did not seem to encounter any instruction set issues with using a 486.

I did not experiment with swap, so I don't know when it helps or hurts.

I think the best low-end performance would be using a 256MB or 512MB CF-IDE bootable GRUB-MBR, option-2 install. This would minimize the latency of the IDE reads, which are frequent with low ram, esp with large complex programs. If swap is used, it should be a separate, real hard drive -- but tests would be needed to ensure the presence of swap was not slowing things down.

A drive with some bad spots but a good usable portion might be a good swap host, esp for a transient public-access type workstation.

*** Is Puppy usable on a 486? ***

Only for special purposes. The command line is very usable. There might be special uses that would be suitable to an old laptop. Loading a CF-IDE or hard drive on a faster computer, and transplanting it into the older computer is the most practical way to set Puppy up.

*** What is the best way to use Puppy on a low-end Pentium? ***

If ram is limited, then the above logic applies. If it is feasible and practical to configure well over 64MB or ram, then a standard Puppy install that loads usr_cram.fs completely into ram at boot time might give the best performance later.

Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#4 Post by Sage »

Your more rigorous investigations concur with my findings. I have standardised a procedure for recycling old HW. Set up Puppy on an HD using a modern chassis. The HD should ideally be ~500Mb (300 seems less reliable, but might work), swap partition of at least 30Mb (50 and more, preferable with theory calling for 2xtotal RAM) and 68pin memory of >=32Mb (no luck with 30pin, so far). Of course, all this imposes severe pressure on detection when HDs are swapped amongst radically different systems. Several correspondents have urged BK to look seriously at Hr. Knopper's detection mechanism; maybe this is the time to reassess this option?

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#5 Post by kethd »

Do you have any tips on the problems you have experienced, "when HDs are swapped amongst radically different systems", and the best solutions you've found?

When you say 68pin, I think you mean 72pin SIMMs.

I don't think there should be any problem running Puppy with 30pin SIMMs. Except that the largest standard 30pin is 4MB, and most such chassis only have 8 slots, so 32MB is going to be the general max. Which means that standard Puppy will only just barely boot -- you'll do much better with an HDoption-2 type install.

I hope to study swap space someday. I do not trust what "everyone says" -- I want data! Lately I am wondering, What are the potential dangers of Too Much Swap, what size would be in danger of being seriously too much, and how would you know that you were having that problem? Any good links?

I'd love for Puppy to autoconfigure during each boot as well as Knoppix. Hope to learn enough to someday help that happen -- doesn't seem like it would be a major distro-size issue, more a matter of just making those bits smarter!

(Having spent days testing various hardware with a stopwatch, I'd like to post my results, maybe in the wiki -- but I don't know of any easy practical way to make tables of such. I guess you can sneak html into the wiki, but don't know how many hours I want to spend learning about table formatting just to accomplish this one task...)

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#6 Post by Lobster »

kethd wrote: (Having spent days testing various hardware with a stopwatch, I'd like to post my results, maybe in the wiki -- but I don't know of any easy practical way to make tables of such. I guess you can sneak html into the wiki, but don't know how many hours I want to spend learning about table formatting just to accomplish this one task...)
To create a table use this code:

Code: Select all

{{table columns="3" cellpadding="1" cells="BIG;GREEN;FROGS;yes;yes;no;no;no;###"}}
to give:

BIG GREEN FROGS
yes yes no
no no

### means the cell is empty.
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#7 Post by Sage »

Sorry, no tips except to keep trying, then give up. Older kit used to suffer massive (in)compatibility issues at the best of times! Type 2 installation is the only type that interests me. This is one HW freak, the SW side leaves me cold - complete ignoramus in that department. I leave that side to BK and the gang.
For reasons that elude me, 68pin and 72pin terminology was used interchangeably at that time. There are 72 contacts. Some hangover from the parity game? The single/double sided issue? Although we weren't using parity strips except in a few proprietary machines.
30pin can be had in 8 and even 16Mb strips. These cost a fortune at the time, but, now, nobody wants to know; I have boxloads of 30pin - not even sure whether it's worth keeping as it tended to age poorly and often leaked bits, in some situations. Being non-standard, the higher values will not run on all boards. Way back then there were other compatibility issues to contend with. The problem is that many good boards don't have CD boot in the BIOS or other vital features. It is not clear to me, yet, why otherwise viable chassis with 30pin memory won't run Puppy. other things being equal. Probably a fruitless venture, but it keeps me off the streets.
You may be correct about the swap issues - a bit like cache thrash. But I haven't observed any audible evidence where swap is being preferred over main memory.
PS. Huh! On rereading, I rechecked - those 8 & 16Mb strips in the spares box are 72 pin! Time rolls on, memory fades!

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#8 Post by kethd »

Sage,
I thought I was the only dinosaur surviving, with boxloads of pounds and pounds of old memory... You can probably sell it on eBay for precious metals recovery. PentiumPro chips can actually be sold for about $5 each for the gold!

Even 4MB 30pin SIMMs don't work in all boxes (the refresh cycle is different from the 1MB, sadly). I think you mostly needed matched sets of four. Some boxes required jumper settings for each memory population pattern.

(I remember testing hardware with refresh failure -- As long as it was used actively, it ran fine, but leave it on idle and it crashed, from lack of the implicit refresh from active memory use.)

Puppy did not work in a Dell XPS P60. Did work in Gateway P120 and Unisys 486DX2-50. So I assumed it would mostly be compatible with older hardware. I'll have to haul out a 30-pin box and try it someday... Maybe even a 386...

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#9 Post by kethd »

Oops - my memory circuits were on the fritz re 30pin SIMMs...

Of course, you can only use 4MB sticks in mainboards designed to support them. The refresh issue is 2/3 chip sticks vs. 8/9chip sticks. The 4x ICs used on the higher density sticks have different refresh requirements than the older 1x chips. So all mbds support 8/9 chip 30pin SIMMs, but 2/3 chip sticks will only work in later mbds designed for them.

Maybe 486s required matched sets of 4, but previous mbds worked with smaller sets?

The best general resource for old hardware details (jumpers etc) info is TotalHardware99. But I have never seen the original CD (with the full graphic illustrations) for sale. Google has the data, but it would be nice to have the whole database offline.

Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#10 Post by Sage »

Dinosaur?! If you dig down a lot further below the KT boundary, you'll find my ancestors in a previous genera in the Carboniferous, before earlier mass extinctions!
Some BIOSes were able to adjust memory timings on 486/386, but I doubt even Rojaks Pot could give definitive advice. It was a can of worms back then. Running Puppy on such machines has to be the ultimate intellectual challenge (did someone mention 286?!).
It would be nice to see a reduced version of Puppy, say 5Mb. There are CLI versions of Linux running off a single floppy, but most folk don't do CLI, so a basic GUI is probably a sine qua non? It used to be possible to run desktop publishing with a mouse in 128K in 8 bit. Maybe video memory can be redployed? If that's a stupid suggestion, remember, I don't do SW !

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#11 Post by kethd »

That reminds me of a favorite stupid-idea hardware daydream:
Now that x86 cpus have on-chip cache as large at 1MB, is it possible to build a minimal computer with zero main ram, as long as you keep within that 1MB? A specialized computer with just cpu, ROM, and some bridge chip for ser/par/kbd/mse/usb/net ports?

As you point out, 1MB used to be more than enough to do most anything on a computer.

One kind of stripped-down pup that should come out with each version is minimal-size bare-bones that has just enough to download/add whatever modules are wanted. This is esp needed until there is a very easy way for users to take pieces out of the standard pup and remaster it, with minimal understanding required.

Another kind of reduced pup that should be issued from time to time is a rather minimal non-GUI CLI-only version. Not of much general interest, since it kind of leaves most of Puppy out of Puppy, but useful to those of us in the Puppy Universe who have special needs, instead of having to use another distro that we are less familiar with.

It is really such a waste to be burning Puppy LiveCDs that only use 10% of the CD! Those of us with fat pipes (I only have good access once a week or less) could just as easily be downloading a much larger ISO that contained a multi-boot CD that had five different kinds of pups, and other interesting compact distros, too...

HaJo
Posts: 27
Joined: Wed 15 Mar 2006, 00:05
Location: DE

#12 Post by HaJo »

kethd wrote:It is really such a waste to be burning Puppy LiveCDs that only use 10% of the CD! ... a much larger ISO that contained a multi-boot CD that had five different kinds of pups, and other interesting compact distros, too...
The Ultimate Boot CD (http://www.ultimatebootcd.com)
has a framework for several bootable images on a single CD.
The "full version" also contains INSERT "Inside Security Rescue Toolkit",
a Knoppix-based small Linux (but that is a quite old version).

It would be very possible to tailor such a CD as you wish,
e.g. replace INSERT with Puppy...
-HaJo

Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#13 Post by Sage »


mpd
Posts: 13
Joined: Fri 17 Mar 2006, 18:10

#14 Post by mpd »

kethd wrote:...rather minimal non-GUI CLI-only version. Not of much general interest, since it kind of leaves most of Puppy out of Puppy, but useful to those of us in the Puppy Universe who have special needs...
I'm working on getting a CLI-only version of puppy to install on an 8meg compact flash. I've got it pretty close to working, but something in the startup scripts is causing the keyboard to not work at all. During the boot process, I can hit ctrl-c and have a partially booted system that the keyboard is still working, but I haven't found the culprit yet.

I did away with using usr_cram.fs, pup001, and just keep everything in the image.gz.

Eventually, this will be installed on a headless box and will use music player daemon to play music losslessly compressed with FLAC. My music is stored on a usb disk.

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#15 Post by kethd »

mpd,
Keep us posted on your experiments -- and post a copy of your CLI-only min-pup when you succeed!

mpd
Posts: 13
Joined: Fri 17 Mar 2006, 18:10

#16 Post by mpd »

I have gotten past the booting problem as well as a problem with some missing alsa files that were keeping me from being able to get the sound card active.

Seems it was sticking on "modprobe usb-ohci" when I had it in a script. By sticking, I mean that it completly disabled my ps2 keyboard. It was odd because I could do the "modprobe usb-ohci" by typing it in manually and it would not stick. I ended up just doing "modprobe usb-storage" and "modprobe ehci-hcd" in my script and that worked.

I just need to clean up a few things to make it neater as well as shave off as many bytes as I can, since I am about a megabyte over my 8 meg target size.

mpd
Posts: 13
Joined: Fri 17 Mar 2006, 18:10

#17 Post by mpd »

To install, I made a dos partition on either a hard drive or a compact flash card in a CF-IDE adapter. Unzip and copy the files to the dos partition. Boot a puppy cd and run "syslinux /dev/hda1" or whatever your partition is. Make sure the dos partition is set to be active or bootable with fdisk.

my mpd.conf file is expecting to find the playlist and music directories on /mnt/sda1

mpd starts as I wanted it to upon boot, loads my playlist, sets repeat on, and starts playing

Thanks to MU, you can now download the latest version of pico_pup
Last edited by mpd on Fri 31 Mar 2006, 00:40, edited 2 times in total.

mpd
Posts: 13
Joined: Fri 17 Mar 2006, 18:10

#18 Post by mpd »

Thanks to MU, you can now download the latest version of pico_pup
Last edited by mpd on Fri 31 Mar 2006, 00:39, edited 1 time in total.

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#19 Post by kethd »

mpd,
Thanks for making this available! Hope someone will offer you hosting space for your larger files, so they can stay in one piece!

Post Reply