Puppy 1.0.7beta test iso available

News, happenings
Message
Author
Guest

#31 Post by Guest »

Just tried the '07 beta.....Xorg works with the Neomagic chipset


Regards
BH

Guest

#32 Post by Guest »

But after comparing it against ,04 with Xfree86 it seems slow in scrolling through web pages, tho I didn't tweak xorg.conf too much

Regards BH

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

LINLD vs. GUJIN

#33 Post by kethd »

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.

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

#34 Post by kethd »

Perhaps I was too hasty about the 64MB boundary:
"Puppy version 1.0.7 is released. The live-CD iso file is 60.46M."

So, even though I was not able to cram the various files of 107b onto a 61MB CF-IDE (DOS bootable), maybe there is some way to make some 64MB USB devices act like a CD, and have everything fit, even if there is no room for any PUPXXX.

Etienne

Re: LINLD vs. GUJIN

#35 Post by Etienne »

kethd wrote: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.

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...
Hello Puppy users, hello kethd,

First, I am sorry to be late to answer all those mails about Gujin, I was
in holidays for all this time and did not read that much my E-mail to
find the only non-spam mail I got in two weeks. Moreover there has
not been one message containning the word "Gujin" in this forums
for quite some time - I stopped searching the forums every day...

The memory size problem and the time needed is due to the fact that
TINY.EXE in Gujin is decompressing itself the initrd file, and gives the
decompressed version to the kernel. All other bootloaders give the
on disk version. The main reason is to check the content of this file,
by checking the CRC32 of the decompressed data.
Because anyway the kernel has to decompress itself this file, it is
unfair to measure the time to start: all the CPU time needed to
decompress is either before starting the kernel or after starting it.

The main difference (and bad point in some configuration) is that
the kernel will decompress the initrd after initialising the virtual
memory/swap device and Gujin needs physical memory for that
- part of the decompressed initrd cannot be swapped to a swap
device at Gujin boot time.

The problem of checking which data is given in the initrd memory
is quite important because most USB device *do not* report read
or write errors from the medium, and so you can get this kind of
errors after formating a CompactFlash using an USB adapter,
and the standard mke2fs:

> user.crit kernel: EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in directory #1742: unaligned directory entry
> user.crit kernel: EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in directory #1747: unaligned directory entry
> user.crit kernel: EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in directory #1751: unaligned directory entry

This is simply few bytes which cannot be written in one sector.
If you use an IDE->CompactFlash adapter you will see those error
even running a standard Linux kernel, as I did.
You can also copy a big file to the medium and then compare it with
itself to immediately spot the problem.

You seem also to have a problem with the command line length, with
Gujin version 1.2 (I discourage strongly using previous versions, with
tiny.exe the command line is *not* correctly passed - v0.9 is not
good neither for other reasons).
One difference in between Gujin and other bootloaders is that the
name of the kernel file is given as the first parameter on the
command line in some cases - that could explain the small difference:
What is the content of "cat /proc/cmdline" when you are running
into problems?
The other main problem I have is: why do you need so long a line?
This command line is made to be edited by hand so should not
be too complex by design.
Also - I do not treat differently loading in CONFIG.SYS or AUTOEXEC.BAT,
so any difference in command line length is directly due to the
command line length available in CONFIG.SYS "SHELL=" - DOS used
to have a maximum of 80 char for it.

By the way, I do understand why you need to boot DOS and then use
a USB DOS driver on computers which cannot boot from USB devices,
but I am not sure why you want to do so, and so use TINY.EXE instead
of completely installing Gujin on a USB FLASH drive by:

Code: Select all

./instboot boot.bin /dev/sda --disk=BIOS:0x00 --geometry=/dev/sda
(You need to download the install-1.2.tar.gz file from sourceforge and
untar this file using Linux) (adding --full parameter will completely
erase the device and show you if some sectors have write problems)
(The Flash drive will contain a FAT filesystem so you can mount it
and write kernel and initrd to it after initialisation).
At least, booting without DOS solves the license problem (you are not
allowed to distribute MS-DOS) and it solves also the HIMEM problem,
some of them limit the maximum memory block to 64 Mbytes.
Booting with FreeDOS helps there, but it has another problem: the
simulated floppy disk (coming from the USB emulation) interract with
the real floppy and the BIOS disk number may be wrong: that is one
reason why they are displayed if you completely install Gujin in a
USB drive.
Also booting directly helps having a bootable CDROM and bootable
USB drive with the same structure (same kernel and same initrd).

I am not sure I replied to all your questions here, if not feel free to
post answers (I am sorry sourceforge forums are not easier to use,
but because I do not pay for it I cannot complain...)

Etienne.

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

#36 Post by kethd »

Etienne,

Very nice to hear from you!

I think that 1.2 truncates a CONFIG.SYS line shorter than 0.9 does, under FreeDOS under the same conditions. So this would have to be the fault of Gujin? I suggest that Gujin always by default echo the actual commandline it is going to fully process.

linld can accept up to about 256 characters (or eight parameters) to pass to the kernel/init, in a file. This is extremely useful and helpful in Puppy, for potentially troubleshooting rc.sysinit. (Because rc.sysinit is extremely difficult to edit, it is desireable to make it highly flexible based on parameters passed by the bootloader.) Please add this feature, in a way compatible with linld.

I only partially understand the issues with decompressed image.gz, but I am quite sure other DOS bootloaders are over-all more efficient, regardless of who is doing the job when. More to the point, I know for sure that this computer is capable of decompressing image.gz about five times faster than Gujin is actually doing it; I'd be happy to try to work with you to speed it up. (Esp since so far in my experiments only Gujin can bootload a standard Puppy in 32MB.) It seems like maybe the simplest quick fix would be to allow a switch to Gujin to bypass the uncompression that you do and have Gujin just pass the uncompressed file like other bootloaders do? (To test this, be sure to use a computer that is only a Pentium-I.)

Thank you for writing so much detail; I will try to study further.

(We should move this all onto a Gujin thread in Puppy forum, but I am not sure how to do that -- you could start one, and just link to it from here?)

etienne

#37 Post by etienne »

kethd wrote: (We should move this all onto a Gujin thread in Puppy forum, but I am not sure how to do that -- you could start one, and just link to it from here?)
http://www.murga.org/~puppy/viewtopic.php?p=30993#30993

Post Reply