site  contact  subhomenews

PPLOG fix, faster boot

July 13, 2008 — BarryK
I built the latest Puppy and installed to USB Flash. Booted, then tested PPLOG, but got a "500 internal server error". I found that PPLOG needs the 'CGI' Perl module -- the reason PPLOG worked before is because I had the 'devx' file loaded, which has the complete Perl, whereas the 'pup_xxx.sfs' has a cutdown Perl PET package (perl-5.8.8tiny). I added the CGI module and PPLOG worked -- that adds about 400KB uncompressed to the cutdown Perl package, but I reckon it is worth it (it jumps from 2600KB to 3000KB according to 'du').

Hmmm, now that we have a web server in the 'standard' Puppy build, I wonder what other little Perl CGI program gems are out there...

Faster boot
One thing that has been most impressive with UniPup is the fast boot. This has brought home to me that as Puppy has progressed, boot times have got gradually longer. 4.1alpha3 is the worst. It is time for a clean sweep, and to make some tough decisions.

I have applied the fast boot code developed for UniPup to the mainstream "normal" Puppy. Some notes on this:

rc.local0 is eliminated (it has a lot of historical, very tangled code), there is now just rc.sysinit, which calls rc.update,, and
There is no probing of serial devices, nor any autodetection of modems (except of course udevd will autoload any appropriate module it finds a match for). Instead, the intention now is to do the probing after bootup, when the user runs PupDial. The user will also have to manually choose a serial mouse.
By default, pup_xxx.sfs is not copied into RAM, regardless how much RAM there is, unless 'pfix=copy' is specified.
Refined code from the rc.sysinit used in UniPup, to wait for slow hardware without gross 'sleep' lines inserted.

The "normal" Puppy cannot boot quite as fast as UniPup, due to the initrd step of the former -- the init script waits for USB storage to become available, then after the switch_root the modules for some other slow hardware may get loaded (for example PCMCIA) and there may have to be a wait again -- whereas in UniPup the usb-storage driver would be loaded concurrently with the drivers for other slow hardware. However, a full hd intall will get the same fast boot as UniPup.
Anyway, I think any potential slower boot of the "normal" Puppy will only be a few seconds.

A comment on point-2. In many cases a module for a modem will be detected and loaded, and its firmware package loaded, and any install script executed. So, it may be that the modem is still fully autodetected and ready to go. However, true hardware serial modems will not be autodetected, but the "probe" button in PupDial will find it, and set /dev/modem to point to the required device. Some details may need to be worked out though!

A comment on point-3. When boot from a live-CD, the normal thing is to create a save-file at first shutdown, then the 'pup_xxx.sfs' also gets copied to the hard-drive. On subsequent boots, although the pup_xxx.sfs' is not copied to RAM, I found performance to still be good, due to intelligent buffering of memory-reads in RAM by the kernel -- after the first read, the kernel keeps as much in RAM buffer as it can.


long boot

sounds good!
Username: prehistoric1
"The Unipup experiment is getting more and more attractive for me. Every time I see those sleep lines in the init code I get the feeling I used to get from analog delay lines in video designs; somewhere down the line those fixed delays are going to bite us. That "tangled code" has frightened me into passive acceptance on faith. I would need to know more about your relationship to some deity to alter it. It may be possible to use features of normal Puppy at a later stage of the Unipup experiment. The problem at present is that we have not known the cost vs. a simple direct implementation, so we did not know when various tricks actually paid off. I'm afraid the comment about the cgi module in PERL only reinforces my prejudices. (Far too easy to do.) As a first approximation, I assume PERL has no semantics of its own; everything is in various bindings and added packages. This makes reading PERL harder than writing. It also makes the size deceptive. That said, cgi could allow us to run a lot of code. Do we want it?

More speed
Username: lobster
"Glad to hear of the speed up - I noticed the speed increase of Unipup. Further increases possible? 1. Scan for 'esc' to bypass 5 second pause to put in puppy parameters at start up 2. Use this esc time to set a variable for the locale - otherwise default to 'En' 3. Use esc sequence to load a saved sfs-save file or default to last save file 4. Use a lowish res vesa as a default, straight in boot up - then dialog with first boot for set up - internet connection, higher res. etc.

Linux kernel
Username: GreatnessGuru
"> ... I built the latest Puppy ... Linux kernel is out, one patch: "... x86: fix ldt limit for 64 bit ... Fix size of LDT entries. On x86-64, ldt_desc is a double-sized descriptor. ..." Eddie Maddox

Re: Faster Boot
Username: kirk
"That all sounds good. I've been booting pfix=noram for a while, haven't noticed any slow down. And some programs need lots of RAM. Been playing with unipup a bit, once I add the kernel modules and other missing stuff, boot time slows down I think these changes will make it pretty close. If you really want to speed things up, use ext3 in the pup_save file. After I use a pup_save file for a while and it gets lots of files stored in it, about 1/4 of my boot time is spent with fsck.

Faster boot
Username: growler
"Not tried uni-pup .. the slow boot problem is particularly sad with a frugal install and the requirement for a check of pup_save file.. on every boot. Frugal installs make for super easy upgrades and multiple installs etc.. but the boot time is a shocker. On Hiwatha/PPLOG I compiled it on 4.0 when I couldn't find the PET and the binary was 400k + 400k for the Perl CGI we are looking at adding a fair bit. Maybe there are some compile options I didn't choose correctly. However, I expect this does open up a lot of other code though.

Tags: puppy