ugmiker@cs.buffalo.EDU (Michael (what am I wood???) Reilly) (10/26/87)
Hi all..
When I boot up my machine I like to run a couple of dif-
ferent programs to make life easier(don't we all :-). I first
run shell, and then in my .login file I "run" facc,mouseclock,
blitzfonts, and "run" date > lastlogin to put my login time in a
file. I get the [cli x] for the different tasks as they start
up, the order goes something like:
[cli 2]
[cli 3]
[cli 2]
[cli 3]
Now, my question is: could my boot up time be shortened if
I waited for each process to be loaded and running before I try
to load the next one?? The disk drive makes ALOT of
brrrrrt...brrrrrt noises (good description huh?? :-), like it is
jumping back and forth between the programs it is simultaneously
trying to load.
Could it also be that one of the programs I am trying to
load are just fragmented throught the disk (which is 90% full),
and if it is, how could I better "order that program, would I
have to copy the disk, file by file to keep the programs whole???
Thanks all....
mike(r)
==========================================================================
Apathy ??? ahhhh who cares about that ....(besides of course me :-)
==========================================================================
Mike Reilly
University of Buffalo Computer Science
csnet: ugmiker@buffalo.CSNET
uucp: ..!{nike|watmath,alegra,decvax}!sunybcs!ugmiker
BITNET: ugmiker@sunybcs.BITNET <-OR-> ACSCMPR@ubvmsc.BITNEThull@hao.UCAR.EDU (Howard Hull) (10/27/87)
In article <6121@sunybcs.UUCP>, ugmiker@cs.buffalo.EDU (Michael Reilley) writes: > Now, my question is: could my boot up time be shortened if > I waited for each process to be loaded and running before I try > to load the next one?? The disk drive makes ALOT of > brrrrrt...brrrrrt noises (good description huh?? :-), like it is > jumping back and forth between the programs it is simultaneously > trying to load. > Could it also be that one of the programs I am trying to > load are just fragmented throught the disk (which is 90% full), > and if it is, how could I better "order that program, would I > have to copy the disk, file by file to keep the programs whole??? Actually, this one was brilliantly deciphered by Matt Dillon a year ago. The Workbench, as it comes from Commodore, has not been particularly well groomed, even for it's own bootup - let alone yours. Of course, there is no way that the CA programmers could have known what you were going to do on your own particular Workbench disk. However, the order in which files are written to the Workbench disk is critical to rapid boot-up. Following is Matt's article, and after that is the front end of a sample script that I use with the Drew Shell. (Heck, it even copies the file dates over as they were on the source!) I put the write-protected Workbench in df0:, an initialized, installed, and versioned target disk in df1:, the mkbench file in ram: and cd to df1: to issue the command "ram:mkbench" from the Drew Shell. If the resulting Workbench grinds on bootup, try moving the Execute or Run file load position around a little. Methinks that either Execute or some of the things Execute calls are invoked by whatever is in AmigaDOS that reads the Startup-Sequence. After a little fussing with the order of things written to the new Workbench, you can have a quicker, quieter booting system! >From hplabs!decwrl!ucbvax!CORY.BERKELEY.EDU!dillon Wed Nov 12 22:09:06 1986 >Path: hao!hplabs!decwrl!ucbvax!CORY.BERKELEY.EDU!dillon >From: dillon@CORY.BERKELEY.EDU (Matt Dillon) >Newsgroups: comp.sys.amiga >Subject: Streamlining WorkBench >Message-ID: <8611130509.AA23119@cory.Berkeley.EDU> >Date: 13 Nov 86 05:09:06 GMT >Sender: daemon@ucbvax.BERKELEY.EDU >Organization: University of California at Berkeley >Lines: 104 [Insert yer own >'s for the next 105 lines!] I've gotten tired of hearing all the seeks my floppy is making to bring boot from workbench disk, so I did some experimenting and came up with an easy solution. All it involves is a lot of dilligent work. The idea is to start with a blank disk, create the directory structure and files in the same order that the workbench accesses them on boot and while it is executing your startup-sequence. For me, there is also a set of commands I execute from my shell login, so take the following as an example. WORKBENCH BOOT PROCEDURE: (1) Make a blank disk bootable by using the Dos INSTALL program. You now have a workbench diskette which, even though it's blank, will boot and give you a default cli with the default preference settings. You don't even need a startup-sequence (2) Create directories and files in the same order that workbench accesses them. Note that if any of the files doesn't exist, some default will be used: DEVS/SYSTEM-CONFIGURATION -contains preference settings S/STARTUP-SEQUENCE -contains execute script so far, the sequence of commands to setup the boot disk is (using SHELL commands): 'x:' is your old workbench diskette mkdir devs s c l copy x:devs/system-configuration devs copy x:s/startup-sequence s You now want to copy commands executed by the startup-sequence. Assume the following startup sequence (mine): ----------- shell c:.rootlogin endcli > nil: ----------- copy x:c/shell c copy x:c/.rootlogin c My Shell login looks like: ----------- date echo -n "date/time? " addbuffers df0: 30 addbuffers df1: 30 binddrivers echo ram:* >nil: source c:.login #contains aliases etc... input x;if $x;date $x;endif;unset x ----------- Note that I echo ram:* to nil:. This is only to force workbench to load the RAM disk driver. Note that I ask the question to set the date and time, and do the rest of the initialization while the user is typing his responce (none of the commands inbetween output anything), Then I get the user line and set the date. So, we continue copying stuff as follows: copy x:c/date c copy x:c/addbuffers c copy x:c/binddrivers c copy x:l l Note the last copy creates the entire 'l' directory and files. This is mainly to get the Ram-Handler which handles the RAM: device, but all three files are needed to have a properly working workbench. Now BRING OVER THE REST OF THE FILES. This involves creating other directories (such as LIBS), and copying files by hand. Don't trust AmigaDos to overwrite files in the same place on disk, so only copy stuff which isn't already on your new workbench. NOTE that none of my startup commands required any disk libraries. If you have any startup commands that do require disk libraries, you should create the libs directory and copy the libraries in question. The whole idea is to reduce the number of seeks required to bring up the system. For those of you who use the icon-based system, you would have also copied LOADWB and a few of the disk libraries (I'm not sure which ones) over. Don't get the idea that I'm excluding anything... I'm just talking about what you initially put on your workbench diskette. After your through copying that, you copy everything else over (I reiterate to, hopefully, avoid confusion). Now, when I bring up my system, I hear only a few clicks from my drive, and it comes up considerably faster. And if you don't like manually doing this stuff everytime a new version of the OS comes out, write a script to do it. Happy Hacking -Matt Dillon P.S. By only copying what I use, I have 382K free on my workbench diskette. >END of >'s [And here is the front end of my Drew Shell script (HH):] mkdir Trashcan copy df0:Trashcan.info Trashcan.info mkdir devs s c l libs System copy df0:devs/System-Configuration devs copy df0:s/Startup-Sequence s copy df0:c/Execute c copy df0:c/Run c copy df0:c/Echo c copy df0:c/RTClock c copy df0:c/Wait c copy df0:c/If c copy df0:c/Path c copy df0:c/EndIf c copy df0:c/BindDrivers c copy df0:c/LoadWb c copy df0:Setlace Setlace copy df0:c/RunBackground c copy df0:l l copy df0:libs libs copy df0:c/Shell c copy df0:c/.login c copy df0:Disk.info Disk.info copy df0:.info .info copy df0:Setlace.info Setlace.info copy df0:Clock Clock copy df0:Clock.info Clock.info copy df0:Preferences Preferences copy df0:Preferences.info Preferences.info copy df0:CLI CLI copy df0:CLI.info CLI.info copy df0:System.info System.info copy df0:System/.info System/.info copy df0:System/DiskCopy System/DiskCopy copy df0:System/DiskCopy.info System/DiskCopy.info copy df0:System/Format System/Format copy df0:System/Format.info System/Format.info copy df0:System/IconEd System/IconEd copy df0:System/IconEd.info System/IconEd.info copy df0:c/Assign c copy df0:c/Break c copy df0:c/CD c copy df0:c/ChangeTaskPri c copy df0:c/Copy c copy df0:c/Date c copy df0:c/Delete c ... etc, etc, you get the idea, I'm sure... Best Regards, Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull for domain mailers: hull@hao.ucar.edu
farren@gethen.UUCP (Michael J. Farren) (10/27/87)
In article <6121@sunybcs.UUCP> ugmiker@sunybcs.UUCP (Michael (what am I wood???) Reilly) writes: > Now, my question is: could my boot up time be shortened if >I waited for each process to be loaded and running before I try >to load the next one?? The disk drive makes ALOT of >brrrrrt...brrrrrt noises (good description huh?? :-), like it is >jumping back and forth between the programs it is simultaneously >trying to load. Unfortunately, it is a lot more efficient to wait until one program has been completely loaded before trying to load another one. It would seem that no attempt has been made to optimize disk accesses when trying to do simultaneous access to different files; the result, especially with the gronky floppy file system, is a lot of very slow thrashing. It would have been very nice if the Metacomco folk had thought about the file system, even a little bit :-) -- ---------------- Michael J. Farren "... if the church put in half the time on covetousness unisoft!gethen!farren that it does on lust, this would be a better world ..." gethen!farren@lll-winken.arpa Garrison Keillor, "Lake Wobegon Days"
treid@afit-ab.arpa (Thomas F. Reid) (10/27/87)
In article <6121@sunybcs.UUCP> ugmiker@sunybcs.UUCP (Michael (what am I wood???) Reilly) writes: > > When I boot up my machine I like to run a couple of dif- >ferent programs to make life easier(don't we all :-). I first >run shell, and then in my .login file I "run" facc,mouseclock, >blitzfonts, and "run" date > lastlogin to put my login time in a >file. . . . > Now, my question is: could my boot up time be shortened if >I waited for each process to be loaded and running before I try >to load the next one?? The disk drive makes ALOT of >brrrrrt...brrrrrt noises (good description huh?? :-), like it is >jumping back and forth between the programs it is simultaneously >trying to load. > Could it also be that one of the programs I am trying to >load are just fragmented throught the disk (which is 90% full), >and if it is, how could I better "order that program, would I >have to copy the disk, file by file to keep the programs whole??? I have a similar setup for my Startup-Sequence...RUNning programs from the Startup-Sequence. After a little experimentation, I've noticed that my startups go a lot faster (dropped from over 2 minutes to about 1 minute) using WAITs after each RUN (and after LOADWB ;-) I was also having "gronking" problems due to the disk validation cycle...a WAIT early in the Startup-Sequence did the trick. By the way, it works even better if you copy WAIT to RAM:, then use "RAM:WAIT ##" throughout the Startup-Sequence. The first few lines of my S-S look something like this: Copy SYS:C/Copy RAM: RAM:Copy SYS:C/wait RAM: RAM:wait 5 . . . RAM:run execute SYS:S/Time.bat <-- Does a timeset, then echo's to file RAM:wait 8 . . . The amount of time to wait varies. I've played around with it some, and 5 seconds (? it is in seconds, right ?) for mucking around with 1 (small) file on disk (as opposed to RAM:), and 8 seconds for two files (ie, the "execute" command comes off of disk, as well as "S:Time.bat") seem to work well for me. Times may vary for your machine, but those #'s should be good first guesses ;-) And yes, you MUST copy file-by-file ("COPY DF#: DF#:" ALL works well) to "unfragment" your disks. The drop from 2 min to 1 min also included a COPY...ALL in addition to the WAITs, but the WAITs seemed to have more effect than the COPY. TomR // \X/ ARPA: treid@afit-ab.arpa -- TomR // ARPANET: treid@afit-ab.arpa \X/
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/27/87)
:up, the order goes something like: :[cli 2] :[cli 3] :[cli 2] :[cli 3] : Now, my question is: could my boot up time be shortened if :I waited for each process to be loaded and running before I try :to load the next one?? The disk drive makes ALOT of Absolutely. If you have several RUN's in a row, DOS will clash with itself trying to load multiple programs at once, causing all sorts of disk seeking. -Matt
john13@garfield.UUCP (John Russell) (10/29/87)
In article <242@afit-ab.arpa>, treid@afit-ab.arpa (Thomas F. Reid) writes: > In article <6121@sunybcs.UUCP> ugmiker@sunybcs.UUCP > > I have a similar setup for my Startup-Sequence...RUNning programs > from the Startup-Sequence. After a little experimentation, I've > noticed that my startups go a lot faster (dropped from over 2 minutes > to about 1 minute) using WAITs after each RUN (and after LOADWB ;-) If you are RUNning programs that open windows, I wrote a little "wait" program that you can use to run one program, wait until it finishes loading and opens a window (FACC does this, right?), and then go ahead and run another. Advantages of this approach over using WAIT commands include - no tweaking of WAIT times needed, as soon as program 1 loads program 2 starts loading - you can specify a timeout value of some number of seconds, so if you are running programs from more than one disk (eg I can't fit VT100 on my Workbench and sometimes forget to stick that disk in my external drive) you have a chance to swap disks in and out before it goes ahead and starts the next load It's on Fish disk #73, under the name "until" and included with another program called "add"; I don't think there was a great deal of explanation with it so you may have brushed across it without noticing. [ My startup-sequence was recently chopped to the bone again, but if it ever got too long & noisy it might be possible to make "until" wait for some new task entry to be created. This would let you run things like PopCLI (that don't open windows) without drive grinding. ] John -- "The Amiga doesn't really multitask because... because... because when two programs try to write to the printer at the same time, it crashes!" -- who WAS that masked ST owner? (honest to God this is what he thinks)
mxk4585@ritcv.UUCP (10/29/87)
>In article <6121@sunybcs.UUCP> ugmiker@sunybcs.UUCP (Michael (what am I wood???) Reilly) writes: >> Now, my question is: could my boot up time be shortened if >>I waited for each process to be loaded and running before I try >>to load the next one?? The disk drive makes ALOT of >>brrrrrt...brrrrrt noises (good description huh?? :-), like it is >>jumping back and forth between the programs it is simultaneously >>trying to load. What I would suggest doing here is copying all the files you want to execute on the VDO ram disk then execute them from there. That way you avoid the problem of the disk drive head from skipping around. I create a subdirectory on my Workbench disk that contains all the programs that I will only execute once like MACGAG, AutoPoint, RSLClock, etc. when I boot up. I copy all programs in the subdirectory into the VD0 ram disk along with a file called ram-sequence that contains all the programs I want to execute in VD0. After the startup- sequence completes loading the programs to VD0, the startup-sequence will execute the ram-sequence program in VD0. Then all the programs take off at hyper-sonic speeds. If your VD0 disk will survive warm-reboots, then you might want to consider having your startup-sequence check to see if the subdirectory still resides in VD0, if it does - then jump to execute ram-sequence else load the programs back into VD0 again. Else you can just have it setup to delete the programs in VD0 after you are done with them if available memory is critical for you. I find doing it this way drastically reduces my boot-up time provided the programs in VD0 survived through a warm-reboot but even if they arent, its still faster to copy them to ram then execute them from there than doing it from the disk drive.
ain@s.cc.purdue.edu.UUCP (10/30/87)
In article <752@ritcv.UUCP> mxk4585@ritcv.UUCP (Mike Kirkpatrick) writes: >What I would suggest doing here is copying all the files you want to execute >on the VDO ram disk then execute them from there. That way you avoid the >problem of the disk drive head from skipping around. If you do this, either set up your workbench disk so you only need invoke copy once (ie. put everything in a sub directory), or, set your path to include VD0: (1.2 only.. but then, we all use 1.2 now right? :-) and copy the copy program into it first -- then you don't need to read it from disk everytime you call it. -- Pat White UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906
john13@garfield.UUCP (11/01/87)
In article <257@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: > It would seem that no attempt has been made to optimize disk accesses when > trying to do simultaneous access to different files; This reminds me, I have (actually my only copy is on loan for a couple of days) a program that claims to do exactly this. "Eliminate drive multitasking" it says. From the desription I though it was another NoKlickStart, but apparently it does something with trackdisk.device to intelligently arbitrate commands for disk access. I haven't looked at it closely, but I will when I get it back and probably post it (binary only I think) if it's any good. (The name is "Finish" in case anyone else also has it.) John -- "Like, bitchin' man! Totally awesome." -- Valley Spock