OSDev.org

Okay I did some measurements on shutdown and startup speed of Vista Premium. My computer has 1GB of memory and reads from the hard drive at 46mb/s and writes at 31mb/s. The bios takes about 15 seconds to do its thing which is included in the times. Both restoring and starting up include typing my password (2 seconds) and don't stop timing until the start menu will come up.

Time to hibernate: 46 seconds
Time to restore: 46 seconds
Shutdown: 1 minute 2 seconds
Startup: 1 minute 10 seconds

I don't think those numbers are two incredibly bad though. I sure would like to make it startup faster though. Hibernation and restoring times seem pretty tied to the speed of the hard drive as expected.

Some more up/down timings:

Mac OS X 10.4 on 1.33GHz iBook G4 (768MiB, 40GB 5400RPM)
Power button to login screen: 39s
Login screen to Finder: 20s
Loaded all Finder modules: 19s
Boot Total: 1m 18s.

Shutdown Total: 12s. I consider this extremely fast.

Debian GNU/Linux Testing on PIII 933MHz PC (1024MiB, 40GB 7200RPM)
Power button to GRUB screen: 25s
GRUB to KDE login screen: 1m 22s (Lots of disk checks happened here, especially for my ReiserFS partitions. I believe these to be largely unnecessary)
KDE startup time: 15s (fairly quick, considering it's KDE)
Boot Total: 2m 2s. Fair too long, IMHO.

KDE shutdown time: 9s
Time spent in text mode doing not much: 27s
Shutdown Total: 36s.

Discussion
I believe my Mac OS system to be fairly fast to shut down, but average in start up time (it's a bit faster than both my XP and Debian systems though). I was impressed to see how long it took to get to the login screen, but disappointed for how long Finder took to load.
In both cases I had opened no applications, documents, or network connections before I started the shutdown. I've also only mentioned the startup disks of the systems. In these conditions I don't think the document disks really matter much.

Gentoo on AMD64 (1.5GB RAM, 300GB)
Power button to login screen: 48s
Login screen to GNOME: 15s
Shutdown: 11s

EDIT:
State of Internal OS Structure (eg. Portage): FUBAR
State of GNOME: Happy

On my laptop/tablet - a fresh install of Windows XP Tablet PC Edition with only Toshiba's drivers takes around 7 seconds from power off to a usable desktop, and about 10 seconds to shut down.

However, after about 8 months of installing/uninstalling programs and other random bloatiness it now takes around 2 minutes to boot to a usable desktop, and between 2-5 minutes to shut down.

Now when ever I go to college I put my tablet into standby with OneNote 2007 opened and ready. Entering/leaving standby takes around 2 seconds.

The thing I like the most about Linux is how everything is controlled by scripts. Which means you can highly optimise your start-up procedure especially in the power-user distros like Gentoo, Debian, Arch-Linux.
There are none of these programs hidden deep in a registry or anything.

I'm mostly in agreement with Avarok -- the user's system should operate for the benefit of the user, not the apps. If the user wants the system off, then (in general) tough sh*t for the apps. The OS should be able to clear all the disk caches every few seconds, and then there should be a green light that says to the user "you can hit the power button to instant-off the machine any time you feel like it".

But if we are being polite, then this is how I'm planning on doing it:

Apps are not allowed to open dialog boxes at shutdown. All open dialog boxes are automatically closed. Any attempt to open a dialog box after the "shutdown" broadcast will return an error. Any and all unsaved work, open tabs, etc, should be saved in a temp file, with the app choosing some generic name and format. After the next reboot, the app can detect that there was a saved incomplete session, and ask if it should be restarted.

Shutdown messages are a slightly modified version of a standard app exit command message (like you would get from the X button in a standard app window). An app that hasn't been set up to detect the difference between "exit" and "shutdown" will simply perform an exit with no dialogs.

There is a user supplied timeout. Any app that has not blocked itself by that point is terminated with extreme prejudice -- ie. when the timeout triggers, the OS blocks access to all disk write routines for all apps, does one last set of cache flushes, and performs a hard shutdown.

Hihi, I used to have a Gentoo box with self-written rc-scripts that would start from power-button to login-screen in about 30 seconds, with about 10-15 taken by BIOS, and another 5-10 taken by Matrox drivers (used to have G550) flashing the screen a couple of times..

But it's mostly loading stuff from disk that takes time, and the above mentioned setup was written to basicly start everything at the same time. It'd start XDM as one of the first things, so you'd get login box fast. In reality, when I was logging in, there was still usually stuff starting in the background, stuff like Apache/PostgreSQL especially.

And after logging in, it'd take another few seconds to load all the desktop-crap I had (like evilwm, desktop background, mm.. oclock).

Most Linux distributions take ages to boot by default, because the init-scripts start all the components one at a time, and load graphical login screen as one of the last things. The good thing is that you can have nice "starting this [ok] starting that [ok]" on console.. the bad thing is it takes time.

But really, in a complete desktop environment, the problem is that you basicly need several services up before you can start stuff that depends on those. It's easy to set up a Linux box that boots fast into login, but if you start Gnome or KDE or whatever, it's a lot harder to get that to start faster, because of the dependencies. The same problem with Windows.. you need certain services up before you can start stuff that depends on those services...

edit: correction.. it wasn't Gentoo... it was the LFS one that I wrote rc scripts for... sorry about that..

Hi,

bewing wrote:I'm mostly in agreement with Avarok -- the user's system should operate for the benefit of the user, not the apps. If the user wants the system off, then (in general) tough sh*t for the apps.

For a multi-user system things are a bit different - the person shutting the system down might not have any idea what other users are doing, and other users might not know the system is about to be shut down.

However, things aren't too different. For a single-user system it might be the UPS telling the system to shutdown - the user still might not know about the shutdown beforehand.

Offtopic note: While writing this I got thinking about UPSs and how they communicate with computers, and did a search for "UPS protocol". It turned up some things I'd never even considered - mostly this workaround. I didn't realise that supporting a UPS properly could involve changes to boot code and shutdown code.


Cheers,

Brendan

You are quite correct -- but there are still 2 types of possible multiuser shutdowns: "emergency" shutdowns (where there is no time to give the other users a polite warning), and a polite shutdown. On a multi-user system of that sort, what you typically see is a broadcast instant message, that tells all the users that the system is going down in 30 seconds, with a countdown, for polite shutdowns. But the system isn't actually shutting down during that countdown, of course, so it doesn't really count.

Once the system starts to go down for real, I don't think it's wise for apps to suddenly start getting chatty with the users. By default, they should just save their current state, so they can recover later, and block/halt. Especially since their user might not be at their terminal during those crucial 30 seconds. Or in the case of emergency shutdowns, where users have no time to respond. So even there, I still feel that the typical response should be that sessions are saved in generic temp files.

ATX power supplies themselves can also, of course, send "powerfail messages" -- I'm not sure if any systems currently sense them, though. Powerfailures should be handled like emergency shutdowns, but with a likelihood of recovery, if the powerfailure is of very short duration, I think.
And thanks for that link.

Brendan wrote:The text editor opens the file as "read only", reads it into memory and closes the file. Then the user edits the file in RAM. At this point you've got modified data in RAM and no open files.

Now the user wants to shutdown the OS. The disk driver has no modified data and the file system code has no modified data.

This I consider bad design (or, if you prefer 1980's design). With modern hardware (== fast), there's no excuse for a program to even have a "save" option. Of course everything should be saved automatically! Why do I, as a user, have to worry about "saving" anything? Yes, I do want to be able to revert to previous versions, or undo stuff, etc. But I really don't want to save. Of course, in current OSes / applications, I still have to save. It's come to the fact I have a built in "Ctrl-S" idle mode, so I press Ctrl-S automatically after writing a few words or a line of text. But I shouldn't have to!

The text editor asks the user what to do with the modified text file in RAM. The user might want to save the file as a different file name, or they might not want the changes saved at all.

The user just wants to shut down the computer, that was the whole point. If he wants all of the above, he shouldn't have shutdown. And really, if implemented well, the user can do all of that after restarting his computer.


JAL

The O/S has to stop many things during shutdown: 1) applications, 2) services, 3) resources (files, sockets, etc) 4) hardware, 5) itself. And these actions must take place in a specific order.

For a complex O/S like XP with tens of services running, it's logical for the shutdown to take one minute. For me, as a user, it's not a problem that it takes too long, the problem is that sometimes shutdown fails, so I can't simply tell it to shutdown and walk away.

In which case, perhaps any tasks which fail to shut down should be hibernated and the user warned at the next startup - that way, you could guarantee shut down. This is especially important if you are connecting to a remote server over a WAN using VNC. If you have just updated the computer and tried a software reset, you don't want to have to ring someone to ask them to push the power button .

Cheers,
Adam

jal wrote:With modern hardware (== fast), there's no excuse for a program to even have a "save" option. Of course everything should be saved automatically! Why do I, as a user, have to worry about "saving" anything? Yes, I do want to be able to revert to previous versions, or undo stuff, etc. But I really don't want to save. Of course, in current OSes / applications, I still have to save. It's come to the fact I have a built in "Ctrl-S" idle mode, so I press Ctrl-S automatically after writing a few words or a line of text. But I shouldn't have to!

I agree. But people would still hit Ctrl-S anyway. So another idea: implicit version control built into the file system (not a new idea) linked directly to the Ctrl-S combination.

i have this very handy on/off button and that is usually the ,etode of shutdown i use.
My wish i that i can use it knowing that i wont damage my system in anyway and that any swapfiles and stuff will automaticly be deleted upon startup or something simular. Any runing programs with data that havent been saved should be the users responsebility and not the OS'.

Basicly what im trying to say is: "why does it have to be so hard?"

Hang on a second. We're all worrying about shutdown times here. Why do they matter again? The user is just going to walk away from their PC and go and do something else. It's startup we should be worried about, isn't it?

I agree, however it is important to make certain that the computer will actually shut down. Mine wont, just to take an example. It just says: "windows is shutting down". After a periode of time the hdd led stop flashing and then nothing.

There is allso the "reboot" consept to consider, i dont think it differs very much from shutdown, but i would be nice if yo didnt have to wait half an hour for the reboot because of a very long shutdown process.