1 Minute and 8 seconds I think would be perfectly fine for them, my only concern would be that when they are booting the computers up in the morning would mean that they all would be pulling the initrd.gz file over the network at the same time. This takes about 28 seconds over a 100mb network @ 2mb per second, this is what I have timed it at with the stopwatch on my mobile phone.
I think at the Immingham site (which is open 9am-5pm) there are about thirty computers, I dont know if the rather primitive (so I have heard) tftp protocol would allow serving the initrd.gz file out to several clients simultaneously or not. If not 30 computers multiplied by 28 seconds. If it cant boot them simultaneously then that means that its going to take 840 seconds, or 14 minutes, to bring them all to life, which they could live with but wouldnt be great (Ive known many XP computers take longer than this to boot). If it cant boot them simultaneously then its going to mean 7 minutes of every day of someone going around pressing the power button every 30 seconds...I think.
I need to work out if it will boot them simultaneously or not, which would involve me raking out some sort of hub and filling the workshop with three or four zombie carcasses of old computers.
If the smoothwall had a gigabit connection between itself and the hub, AND the tftp server could send the initrd.gz file to all thirty computers at once, then the major bottleneck between the hub and the smoothwall would be eliminated. Ten computers could be booted every thirty seconds. It would take three seconds for the attendant in the morning to walk from one computer to another switching it on in any case.
I think I got those sums right, but my brain is still somewhat battered and bruised.
Anyhow, another matter Ive just noticed. Ive looked in the Hardinfo on the newly netbooted machine, and found out of the total of 385516kb of RAM that is on the machine, there is only only 135252kb of memory available. This means two thirds of the memory is taken up. I believe most of the computers at the cybercafe will be about 512mb of RAM so this is not too much of a problem, but it would be nice to have the extra 100/128ish mb extra to play with.
I have a theory that the netboot protocol on the client machines reserves an amount to copy the the initrd.gz file into. Raffy suggested that 102000kb be used for this, it is defined in the /home/pxelinux.cfg/default file
Code: Select all
DEFAULT Puppy
PROMPT 0
NOESCAPE 0
ALLOWOPTIONS 0
TIMEOUT 100
MENU TITLE Puppy Network Booting!
# Puppy Linux Loader
LABEL Puppy
MENU Puppy Net-Booting
KERNEL vmlinuz
APPEND initrd=initrd.gz ramdisk_size=[b]102013040[/b]
EOF
notice the repeated mistake with the bold tags.
When the client computer boots, the first thirty seconds are spent rolling dots ("."'s)across the screen while the initrd.gz is transfered across the network to it, then the "normal" done done done bootscreen appears as puppy boots. The usual lengthy one where it says
only takes a split second. From what I know of the puppy boot process, normally the pup_420.sfs file (containing all of puppy's programs) would be loaded off the CD or Hard disk media into the computers memory on higher memory machines into RAM to give puppy its speed.
When netbooting, it seems that the pup_420.sfs file is still behaving the same way, ie being transfered from the "disk", ie the netboot ramdisk, into another ramdisk (hence it only takes a second), with the effect that essentially double the memory is being take up, the first chunk for the initrd.gz with the pup_420.sfs file inside, and the second being just pup_420.sfs. On a 384MB ram machine, this leaves just 128mb to play with, rather than 256MB (approximate figures).
I also understand, using boot parameters, it is possible to read the pup_420.sfs file directly from the disk, as would occur in an older machine without enough ram to preload the pup_420.sfs file, i.e. below 128mb of ram.
If netbooted puppy worked in this way, even on machines with a lot of ram, puppy programs would still be loaded into ram from the first chunk (the netboot ramdisk), rather than the second one as is occurring now. This would still mean that the netbooted puppy would open programs just as quickly because both copies are in RAM.
What are the boot parameters to force non-loading of the pup_420.sfs file into a new ramdisk? and where would I put them?