Quick links
- Introduction
- Methods
- Benchmark results
- Boot time video
- Result analysis
- Slackware 2.3
- Windows 95
- Slackware 3.1
- Windows NT 4.0
- Debian 2.0 “Hamm”
- Windows 98SE
- Slackware 4.0
- Windows 2000
- Slackware 7.1
- Windows Millennium Edition
- Slackware 8.0
- Windows XP
- Debian 3.0 “Woody”
- SuSE 9.2
- Windows XP Professional x64 Edition
- SUSE 10.1
- Windows Vista
- openSUSE 11.1
- Windows 7
- openSUSE 12.2
- Windows 8 Consumer Preview
Introduction
Due to scientific curiosity and the fact that Windows 7 on my tablet PC tends to boot fairly slowly, I decided to do an experiment in order to see what operating systems have what boot times. Since a topic like that should be interesting for other people as well, I also decided to share my findings and notes about the experiment here.
Methods
First of all, in order to get valid results, I tried to keep with scientific practises. As such, I will briefly describe the methodology of the benchmark here. There were 21 operating systems tested in total, across a large release span and across Windows and Linux. On the Windows side, all of the releases since Windows 95 have been tested: Windows 95, Windows 98SE, Windows Me, Windows NT 4.0, Windows 2000, Windows XP (both 32-bit and x64 Professional), Windows Vista and Windows 7, as well as the consumer preview of Windows 8. On the Linux side, the tested releases were part of three distributions: Slackware Linux (Slackware 2.3, Slackware 3.1, Slackware 4.0, Slackware 7.1 and Slackware 8.1), Debian GNU/Linux (Debian 2.0 "hamm" and Debian 3.0 "woody") and various incarnations of openSUSE (SuSE 9.2, SUSE 10.1, openSUSE 11.1 and openSUSE 12.2).
The testing was done using VirtualBox 4.1.18. The host system was running openSUSE 12.2 x86_64, the processor was a quad-core Intel Core i5-3470, the system had 8 GiB of RAM installed, and the disk drive was a Western Digital Caviar Black 640GB hard disk drive (in AHCI mode, and openSUSE used Btrfs for storing the virtual images).
The tested guest systems were set up to use the latest available technology that they supported in terms of processor and hard drive performance (multiple cores and IO APIC as well as AHCI). The virtualised RAM amount was generally set to either the one recommended by VirtualBox or the one listed as the hardware requirement for the guest, depending on which was higher. The virtualised video memory size was always set to 128 MiB. The guest additions were not installed on any of the hosts (although later Linux releases had built-in support for them, in which case it was left as it was). No graphics acceleration was enabled. Network, sound, serial and USB interfaces were all disabled.
The tested systems were all customised to include the bare minimum that is capable of displaying a graphical server and running a graphical terminal, so that any additional software would not have an adverse effect on boot speed. The boot speed was calculated by recording the boot process and using a frame-by-frame count starting from the first frame after the virtual BIOS hands over the boot process to the guest bootloader and ending with the first frame that shows the fully loaded desktop with the fully loaded terminal window. Similarly, the halt times were calculated by starting from the first frame after the halt command was given or the button was released and ending with the first frame after the virtual machine closes or, if the system does not power it off, with the first frame that no longer changes until the guest system is manually turned off. All tests were carried out at least three times.
There were different nuances concerning some of the operating systems which I will describe after the result list, as well as my thoughts on the difference in boot times between the systems. The benchmark results are listed in the next page.
Benchmark results
The results, in graphical form, are below:
Ordered strictly by boot time, the operating systems would be in this order:
- Windows 98 Second Edition
- Windows Millennium Edition
- Windows 95
- Slackware 3.1
- SUSE 10.1
- openSUSE 11.1
- Slackware 2.1
- Windows XP Professional x64 Edition
- Windows XP
- Slackware 4.0
- SuSE 9.2
- Slackware 7.1
- Slackware 8.0
- openSUSE 12.2
- Windows Vista
- Debian 3.0 "woody"
- Windows NT 4.0
- Windows 7
- Windows 2000
- Windows 8 Consumer Preview
- Debian 2.0 "hamm"
In addition, here are graphs showing the change in boot and halt speed over time in different operating system families:
In addition to the graphs, I made a video demonstrating the boot process of each OS which you can see on the next page. Also, the raw data can be found on the last page of this article.
Boot time video
The following video shows the exact process of booting into each of the operating systems, all of the three or four times that were tested.
(Video under construction, check back later.)
Result analysis
I will start my analysis just like I did the benchmarking - in chronological order.
Slackware 2.3
The first operating system that was benchmarked was Slackware 2.3. Below you can see a reference table showing what options I used when setting it up. A similar table will be included after each subsequent operating system that was benchmarked.
RAM amount |
64 MiB |
Release date |
1995 05 |
---|---|---|---|
Enabled cores |
1 | Kernel version |
1.2.8 |
Enabled IO APIC |
False | Graphical server |
XFree86 3.1.0 |
Hard disk interface |
IDE | Window manager |
Fvwm |
I did not mention the display manager, because in all of the tests (except the first few) I used XDM, as it's built-in and extremely lightweight.
Slackware in general is one of the oldest Linux distributions out there, and the 2.3 version was one of the earliest releases. The installation is based on floppy disks. You need to set up the disks before installing - they are provided in file form, expecting people to write files into floppies by themselves. This creates a bit of a problem in terms of virtualisation, as there are no images that could be mounted, and VirtualBox does not provide any means to create a virtual formatted floppy. The solution to the problem was using mkfs to create a file of the floppy size that is formatted with VFAT, then mount it on a directory and copy the files into that directory. Once unmounted and the new file given the IMG extension, VirtualBox identified it as a raw floppy image and the installation could continue. There are quite a few floppy disks that have to be written (as containing a graphical server on floppy disks is not an easy task), so I ended up making a small script that automated the process.
The installation utility allowed me to select packages to install, as well as install certain kernel modules. I made sure that the mouse module is installed, and nothing but the base disk set and the XFree86 disk set was installed. Configuring the X server to start correctly was not easy (apparently, you cannot use the SVGA driver as it defaults to an incredibly tiny resolution, so I had to use the VGA driver instead).
I could not find a way to autostart the X server (it was an uncommon application to use back then, after all), so I had to use the startx command manually to start it. When calculating the boot time, I summed the time it took to boot into the console and the time it took to launch the desktop after issuing the startx command to get the complete boot time.
There is also no graphical way to shut the operating system down (it is a function of the display manager, and in this case it was skipped altogether; later XDM was used as the display manager, but it does not provide the shut down functionality). Hence I had to shut it down using the terminal. The command to do it, halt, without any switches waits 10 seconds until it starts shutting the system down, but it had the -q switch available for fast shut down, which I used to greatly boost the shut down speed.
Looking at the results, Slackware 2.3 did a pretty good job. The sub-9-second boot time is really good, while the sub-2-second halt time is just incredibly fast. It is not very surprising, however, since the system itself takes a very small amount of space and has relatively few functions, so it does not have a lot to load during boot.
If you wish to recreate the test on your own hardware, or have some other interests in this or other versions of Slackware, you can download its images from this website. Note that in order to get the floppy disks to work on VirtualBox, you need to rename them to have the ".img" extension.
Windows 95
RAM amount |
64 MiB |
Release date |
1995 08 |
---|---|---|---|
Enabled cores |
1 | Kernel version |
Windows 4.0 |
Enabled IO APIC |
False | Theme |
Standard |
Hard disk interface |
IDE |
Windows 95 is the first Windows operating system that had a stand-alone installer (that did not depend on a pre-installed DOS environment), hence I chose it to be the start of the benchmark (and put different Linux distributions between Windows releases, as they are a lot more common than Windows releases).
The Windows 95 installation process is fairly standard for its time. I used the floppy version for installation. The installer is nice enough to offer you a choice of what to install. Naturally, I deselected everything to keep it light-weight (the graphical terminal cannot be unselected, of course).
Other than unselecting certain applications, the system does not provide any straight-forwards ways of trimming it down further. At this time, the concept of services was still not finalised (and the service management tools were never included on the Windows 4.X branch, only the NT branch). In addition, there were no performance options like in later Windows releases, as the features that the options turn off were not implemented back then to begin with.
Looking at the results, the operating system fared really well. It beat Slackware 2.3 by nearly 2 seconds in boot time. However, during testing, there was an issue where the OS would refuse to boot with an error (seemingly randomly, as a reset would allow it to run once again). The issue was made a bit better by applying a hotfix for fast processors, but was never eliminated completely. The halt time is nearly the same as that of Slackware 2.3, and is the fastest from all of the tested operating systems.
Slackware 3.1
RAM amount |
64 MiB |
Release date |
1996 06 |
---|---|---|---|
Enabled cores |
1 | Kernel version |
2.0.0 |
Enabled IO APIC |
False | Graphical server |
XFree86 3.1.2 |
Hard disk interface |
IDE | Window manager |
Fvwm |
There is very little difference between the installation procedures of Slackware 3.1 and Slackware 2.3. The new version comes with the Linux kernel 2.0.0, which was the first kernel version to support Symmetric Multiprocessing (multiple processors/cores). I did not bother to enable more cores, however, as it appears that the SMP functionality was not yet built into the kernels shipped by Slackware at the time.
When installed, however, there seemed to be a few problems that were not present in the previous version. Some of the installed packages seemed to invoke other packages that did not exist. In the video, you can clearly see them. And while this seems to have been mostly an issue with the visual neatness, there was a bigger problem, namely that the OS refused to halt correctly. When the command was issued, the system would hang instead of exiting gracefully, therefore there was no reliable way of knowing how long the shut down process takes.
Looking at the numbers, the boot speed has improved since the last version quite a bit. With just below 7 second boot time, it matches the boot speed of Windows 95 and earns the position of the fastest-booting Linux distribution version in the tested range. Though, as mentioned, the halt times could not be measured, which is obviously a rather serious issue for normal use.
Windows NT 4.0
RAM amount |
128 MiB |
Release date |
1996 08 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
Windows NT 4.0 |
Enabled IO APIC |
True | Theme |
Standard |
Hard disk interface |
IDE |
Windows NT 4.0 installation is quite similar to the one in Windows 95. It seems that the installation programs did not branch out so much compared to the operating systems themselves. Once again there is a possibility to disable unneeded components. The version of the system that I installed was Windows NT 4.0 Workstation Service Pack 1.
Windows NT 4.0 is the first Windows operating system to support Symmetric Multiprocessing (although it mistook 4 cores that I have for 2). Its memory usage is also higher, but still minuscule compared to the RAM sizes of today. The resolution that it set after install was 800x600 (as opposed to Windows 95 640x480), so I also set these parameters the same way when testing later Linux installations.
The system itself does have a service management application (interestingly enough, the icon from WinNT 4.0 stayed the same up until the moment of writing, as it is used even in Windows 8 CP). There are very few actual services running, however.
The boot speed of Windows NT 4.0 Workstation leaves a lot to be desired. It is one of the slowest-booting systems in the benchmark, taking over 25 seconds to boot completely. I suspect that there is some sort of bug that prevents it from performing better, as most of the waiting time is spent in a blue screen that shows the OS version and some of the detected hardware, without any disk I/O happening in the background. Personally, I find 20 seconds to be the line between relatively fast and relatively slow boot, so the boot times of this OS version is far from optimal.
Looking at the halt speed, it also took notably more time than Windows 95 and most other Windows versions. With all that, it seems that Windows NT 4.0 Workstation is one of the worst performing systems in this benchmark.
Debian 2.0 “Hamm”
RAM amount |
128 MiB |
Release date |
1998 07 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
2.0.34 |
Enabled IO APIC |
True | Graphical server |
XFree86 3.3.2 |
Hard disk interface |
IDE | Window manager |
Fvwm |
Debian 2.0, codenamed "Hamm", is the first Debian distribution in the benchmark. I originally planned to test more Debian releases, but unfortunately previous versions due to a bug in installation media verification process could not be installed. That, combined with the slow release cycle of Debian, made it so that only two versions of Debian were tested in the benchmark.
The Debian installation process in Hamm is both similar and different compared to the one in Slackware. For one, both still used text-only installers, and allowed to select certain kernel options and packages to install. But dselect, the package management tool Debian used, is quite a bit more thorough compared to package selection in Slackware. That means that more packages could be deselected, making the installation lighter, although it took longer to set it up.
Debian 2.0 was the first distribution where the X server is automatically started. However, as it uses XDM, there is no way to automatically log in. So I still had to count the boot time as the sum of booting up to the point where you can enter the password and the time period after the Return key was hit and the full desktop is shown.
Unfortunately, the boot times of Debian Hamm turned out to be even worse than those of Windows NT 4.0. As a matter of fact, Hamm turned out to be the slowest booting system in the benchmark. It seems to be some kind of a bug prevents it from booting faster (it seems to experience a soft freeze twice during boot, and both times look related to SCSI devices, although none have been virtualised to begin with). Needless to say, a boot time that is longer than 39 seconds is simply unacceptable.
Speaking about shutdown times, Debian was the first Linux version that used the shutdown command successfully, and since the -q option was removed from it, it took longer to halt the system than all of the previously tested OSs, but it is a start of a rather uniform halt time we will observe in later Linux releases. I am not certain whether this way of shutting the system down had a preset waiting time before killing programs (like the halt program had back in Slackware 2.3), or intelligently shut the system down once all the programs exited, or a combination of the two.
If you wish to test such early versions of Debian, see this website.
Windows 98SE
RAM amount |
64 MiB |
Release date |
1999 05 |
---|---|---|---|
Enabled cores |
1 | Kernel version |
Windows 4.1 |
Enabled IO APIC |
False | Theme |
Standard |
Hard disk interface |
IDE |
Windows 98 Second Edition was the second operating system of the Windows 4.X family tested in the benchmark. As such, it doesn't support SMP and does not require any more than 64 MiB of RAM to function to its full potential.
The installation procedure is extremely similar to that of Windows XP, only using a less flashy interface and Windows 3.1 looks. Just like the previous Windows versions, it allows you to deselect certain programs to make the installation lighter.
Once again, just like with Windows 95, there is no way to control system services and there are no performance settings to set. So aside from removing all of the unneeded components at install time, the system was tested in a fairly vanilla state.
Looking at the results, the operating system fares extremely well. As a matter of fact, its boot time of just over 5 seconds secures the first place in this benchmark. It is somewhat surprising, given that Windows 98SE is a bit larger than Windows 95, while pretty much every other setting is the same, so it would seem that it is boot optimisations that allows Win98SE to come out on top.
The halt time results are slightly less fascinating, but still close to the best. The halt time of just below 2 seconds makes it the slowest-halting system from the Windows 4.X range, but this range by itself is the fastest-halting compared to all other Windows versions. So overall the most popular old-time Windows OS performed extremely well in this benchmark as well.
Slackware 4.0
RAM amount |
128 MiB |
Release date |
1999 05 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
2.2.6 |
Enabled IO APIC |
True | Graphical server |
XFree86 3.3.3.1 |
Hard disk interface |
IDE | Window manager |
Fvwm2 |
Slackware 4.0 installation procedure is very similar to the previous versions of the distribution. The only major differences are that it now comes on a CD instead of on floppy disks, and the package selection utility has been made slightly more sophisticated.
The installed system uses Fvwm2 instead of Fvwm as the default window manager, although Fvwm and twm are accessible though the menu. The reason why I did not try to set up twm as the default is that it did not seem to have an option to call xterm, which is a prerequisite for benchmarking. However, twm, Fvwm and Fwvm2 are pretty much equally light-weight.
The benchmark numbers show that Slackware 4.0 is not nearly as fast as its predecessor Slackware 3.1, but also not nearly as slow as Debian 2.0 was. The boot time of nearly 13 seconds is not too long to be annoying, even if it's considerably longer than that of Slackware 3.1.
Looking at the halt times, as mentioned in the overview of Debian 2.0, the halt time seems to be identical to it.
The CD images for early Slackware versions can be downloaded here.
Windows 2000
RAM amount |
168 MiB |
Release date |
2000 02 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
Windows NT 5.0 |
Enabled IO APIC |
True | Theme |
Standard |
Hard disk interface |
IDE |
Windows 2000 is the first system supported by nLite, a Windows disc configuration utility which can be used to drastically trim down the features of the system to make it very light-weight. I did just that before the installation. It takes a while to configure all the options, but in the end the system is trimmed down a lot more than it would otherwise be. The installation process is similar to that of a normal program, it's a wizard-based setup. It's a lot less flashy compared to Windows 98 setup, which shows that Windows 2000 was geared towards professional users as opposed to home users (even if Microsoft already had a plan to obsolete the Windows 4.X family at that point).
Using nLite and the service management program in the OS, I turned off all of the unneeded services (this OS version already has quite a few of them). I also disabled certain visual features such as menu scrolling animations. There are no other relevant performance options to choose from in Windows 2000.
Looking at the benchmark results, you can see that the boot time of Windows 2000 is nothing short of a disaster. It takes over 34 seconds to boot to the desktop. The boot process consists of 3 steps, all of which seem to take longer than they should. This puts the operating system just below Debian 2.0 and makes it the slowest booting complete Windows system of all tested in the benchmark.
At least the sub-3-second halt time is overall pretty good and a marked improvement over Windows NT 4.0, if still not as good as that of Windows 98.
Slackware 7.1
RAM amount |
168 MiB |
Release date |
2000 06 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
2.2.16 |
Enabled IO APIC |
True | Graphical server |
XFree86 3.3.6 |
Hard disk interface |
IDE | Window manager |
Fvwm2 |
There are very few changes between Slackware 7.1 and Slackware 4.0, despite the difference in versioning.
And so the benchmark results are also not very surprising. In one year, not a whole lot has changed and even the boot time stayed similar. It only increased by a second. The halt results are the same as in the previous version.
Windows Millennium Edition
RAM amount |
64 MiB |
Release date |
2000 09 |
---|---|---|---|
Enabled cores |
1 | Kernel version |
Windows 4.9 |
Enabled IO APIC |
False | Theme |
Standard |
Hard disk interface |
IDE |
The setup process of Windows Millennium Edition is the most different from all of the other Windows versions, and is quite similar to very early Linux installation procedures before it boots to graphical mode. You need to run things like fdisk and format manually before starting the graphical part of the installation. The graphical part is quite similar to the one from Windows 98SE (and allows deselecting unneeded components like it) and Windows XP.
Once installed, it is just like Windows 98 in that it has no real configuration options. There is no service configuration.
Looking at the benchmark results, Windows Me does not only feel like Windows 98, but it also performs like it, which is to say very well. The 6-second boot time is just one second longer than that of Windows 98SE.
The halt time is just one and a half of a second, which is pretty much on par with Windows 95 and Slackware 2.3, the fastest halting systems tested in the benchmark.
All of this puts Windows Me in a rather unique place. It is the last of the Windows 4.X range, which means that it keeps a lot of archaic traits from Windows 98 and Windows 95, but also keeps their strengths, such as quick boot and halt times. And since it is the latest version, it has certain features that the previous versions lack, such as USB support. There are also some (although rare) applications and drivers that run on Windows Me but not on previous Windows 4.X versions. So, as such, Windows Me, even if loathed at the time of its release, becomes a sort of sweet spot in this benchmark.
Slackware 8.0
RAM amount |
168 MiB |
Release date |
2001 07 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
2.2.19 |
Enabled IO APIC |
True | Graphical server |
XFree86 4.1.0 |
Hard disk interface |
IDE | Window manager |
twm |
Slackware 8.0, while still similar to its predecessors, have a few important changes this time around. One of them is the introduction of the VESA driver recommendation for use during early boot. That allows the resolution to change to our desired one early on. The XFree86 4.1.0 server is quite a milestone, too, as it marked a change in its configuration policy.
However, when using base X, for some reason Slackware 8.0 did not set up automatic boot to xdm, so I had to use the earlier method of starting the X server manually. Also, it defaults to twm as the base window manager, and not the previous Fvwm2.
The benchmark results show that the boot time hardly changed at all since the last version, in spite of the installer's warning that setting a graphics mode early in the boot process could make the process slower.
The halt time is a bit more interesting, as there is a noticeable jump in it compared to its predecessors. It appears that it spends a lot of time trying to synchronise the "hardware" (emulated) clock with the software clock.
Windows XP
RAM amount |
192 MiB |
Release date |
2001 10 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
Windows NT 5.1 |
Enabled IO APIC |
True | Theme |
Classic |
Hard disk interface |
IDE |
Windows XP is the second OS that is supported by nLite. Once again configuring the OS with nLite takes a long time, but in the end the installation medium size is cut down in half if not more, as well as making it easier to deal with services by removing or disabling them before the system gets the chance to run in the first place.
Note that here I tested the x86 Windows XP, and the x86_64 version was tested later, since it uses an entirely different kernel and was released way later than the original Windows XP.
Normally, when installing Windows XP, the setup procedure is similar to the one introduced in Windows 98. However, using nLite I enabled the Windows 2000-style installation procedure, which makes the installation less flashy and more similar to installing a regular program.
nLite also allows disabling many of the additional graphical effects, which I did. I also made sure that all of them are deselected in the Performance tab of the computer properties window. That disabled animations, cursor shadows, font smoothing and themes (I had themes disabled by disabling the theme service, too).
The only services that were selected to boot on start were the ones that are critically needed. That means that the system ended up not being capable of networking or extended security. Note that the point of the benchmark is to see how the base systems compare with each other, not counting available features.
Looking at the benchmark results, it is obvious that Windows XP achieved a lot in terms of boot speed compared to its NT predecessors. The boot speed of just below 11 seconds is really good, even if it's not as good as the Windows 4.X line managed to achieve.
The halt time of 4 seconds is also pretty good, although it is not as good as the Windows 4.X line or Windows 2000 managed to achieve.
Debian 3.0 “Woody”
RAM amount |
192 MiB |
Release date |
2002 07 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
2.4.18 |
Enabled IO APIC |
True | Graphical server |
XFree86 4.1.0.1 |
Hard disk interface |
IDE | Window manager |
twm |
The installation procedure of Debian 3.0 is not too different from Debian 2.0, just with more options and slightly more user-friendly (although that's mostly due to how the ISO is laid out).
The default barebones X window manager choice for Debian 3.0 is twm, although it's quite a bit modified from the stock twm that you can see in nowadays distributions. This one has a much more elaborate menu with submenus. It's still lightning-fast to start, though.
However, as you can see in the benchmark results, this doesn't help Debian that much. While its boot speed is no longer broken like it was in Debian 2.0, but it still boots slower than it should. The near-23-second boot time is still the second worst result from all of the tested Linux distribution versions.
The halt time is not as bad as it was in the last tested Slackware release, and is closer to the result of Debian 2.0. It's still slower than any of the tested Windows versions.
It is quite unfortunate how the Debian tests turned out, as both of the tested versions performed rather poorly. The original plan was to use Debian as the base for benchmarking until the first still-available SuSE version, but due to installer bugs and slow release cycles only two versions of the distribution got tested in the end.
SuSE 9.2
RAM amount |
256 MiB |
Release date |
2004 10 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
2.6.8 |
Enabled IO APIC |
False | Graphical server |
X.Org 6.8.1 |
Hard disk interface |
IDE | Window manager |
twm |
Even though earlier I always had one Linux version following every Windows benchmark, this time we have two. The reason for that is that for a few years there were no Windows releases on the desktop. In that time, a lot of the components in Linux advanced. Slackware 8.0 ran on the 2.2 kernel; Debian 3.0 ran on the 2.4 kernel; and SuSE 9.2 already runs on 2.6. Also, the XFree86 X server was superseded by the X.Org X server.
Another very important change that happened between the two last Linux releases was the start of x86_64 architecture support. From here on, all of the tested operating systems are 64-bit.
SuSE 9.2 is the first version of the SuSE (later SUSE and openSUSE) distribution that is still available on the internet to this day. But even finding that was extremely difficult, as the vast majority of links are dead. The fact that Novell did not use to create ISOs until a bit after the distribution's release date did not help archive longevity either.
The installation procedure for SuSE 9.2 is very similar to what it is with the current openSUSE releases - it's based on YaST. It's a graphical mouse-driven installer. It allows you to choose the packages you want to use, similarly to dselect, which again allows to make the system much more light-weight. The only major difference from nowadays openSUSE installation procedure that I have noticed is that YaST was worse with dependency solving back then, silently deselecting packages and such, which made set up time longer.
There was also one strange issue with the installer - it ran extremely slowly when IO APIC was activated (to the point that it took 30 minutes to only start loading the graphical interface). So I had to pass the noapic kernel parameter in order to get it going. It carried over to the installed system as well.
If you look at the boot time results, you can see that, even despite the fact that it had APIC disabled, it managed to beat Slackware 7.1 with its slightly longer than 13 second boot time. That is due to YaST, which has a graphical tool to disable system daemons (services).
The halt time of SuSE 9.2 is pretty bad, though, at just below 15 seconds. The only worse performer was Slackware 8.0.
Windows XP Professional x64 Edition
RAM amount |
512 MiB |
Release date |
2005 04 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
Windows NT 5.2 |
Enabled IO APIC |
True | Theme |
Classic |
Hard disk interface |
IDE |
The next system tested in the benchmark is Windows XP x64, as, contrary to what its name might suggest, it uses a newer kernel than the regular Windows XP. In essence, it is Windows Server 2003 x64 rebranded.
The installation of it is exactly the same as the standard Windows XP. nLite also supports it the same way.
The benchmark results show that the boot time has decreased slightly since the last release (it is below 10 seconds now). However, the halt time has increased by a second up to just over 5 seconds.
SUSE 10.1
RAM amount |
512 MiB |
Release date |
2006 05 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
2.6.16.21 |
Enabled IO APIC |
True | Graphical server |
X.Org 6.9.0 |
Hard disk interface |
IDE | Window manager |
Window Maker |
With SUSE 10.1, the issue with IO APIC is no more. Otherwise, the installation procedure is pretty much the same as with SuSE 9.2. The system no longer has as many 32-bit dependencies as the predecessor and dependency solving, while still ways off from what we have today, is a bit more graceful.
SUSE 10.1 had a few window managers installed in the default minimalistic X installation, and had Window Maker set as default. Since it is pretty much as light-weight as twm, I left it as it was. Once again YaST helped a lot by disabling all the unnecessary daemons.
The benchmark results show that SUSE 10.1 achieved incredible boot speed. The boot time was a mere 7 seconds - something only the ancient Slackware 3.1 managed to beat from the Linux side. On the Windows side, SUSE 10.1 managed to beat all of the Windows NT line and got just one second short of matching Windows Me.
Without further investigation, it is difficult to say what makes SUSE 10.1 perform so well. It is possible that the proper IO APIC functionality had a positive effect on the boot time compared to the previous version. It is also possible that there was some additional boot time optimisation done on it that allowed for such good boot times. And, of course, the ability to easily disable unneeded daemons helped SUSE 10.1 a whole lot compared to previous Linux versions.
On the other hand, halt speed is still nearly as bad as it was with SuSE 9.2, approaching 14 seconds. The halt time results of this range of OSs suggests that starting from Slackware 8.0, the halt procedure involved waiting a set amount of time before turning the machine off.
Windows Vista
RAM amount |
512 MiB |
Release date |
2007 01 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
Windows NT 6.0 |
Enabled IO APIC |
True | Theme |
Classic |
Hard disk interface |
AHCI |
While nLite supported three of the previously tested Windows versions, it does not support Vista. Instead, there is a separate tool to preconfigure it, called vLite. It works quite a bit like nLite, but with a bit different user interface and, of course, different options that are unique to Vista.
The installation procedure of Windows Vista is different from the one in Windows XP, with everything being done from a minimal graphical environment from the very start. It still doesn't provide any configuration options like the early Windows versions did, thus requiring tools like vLite to trim the system down.
Vista is the first operating system that supports AHCI disks out of the box, so that is what was used in the test and in later Windows tests. Later Linux incarnations also support it out of the box.
The benchmark results show that the boot time of Windows Vista has regressed from Windows XP. It takes nearly 19 seconds to boot it - which is just borderline acceptable. Interesting enough, the fact that Vista has a two-stage boot and the bootsplash graphics are quite different in both, it's not as tedious to look at it, considering the relatively long boot time.
Just like boot time, there is a notable difference in halt time compared to Windows XP x64. It is a bit over 8 seconds, which puts it pretty much in line with Debian 2.0, Slackware 4.0 and Slackware 7.1.
openSUSE 11.1
RAM amount |
512 MiB |
Release date |
2008 12 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
2.6.27.7 |
Enabled IO APIC |
True | Graphical server |
X.Org 1.5.2 |
Hard disk interface |
AHCI | Window manager |
twm |
Once again the installation of openSUSE 11.1 is pretty much the same as for its predecessors. This time I once again chose to have only twm run on boot. Also, AHCI was enabled.
Looking at the benchmark results, the boot time of openSUSE 11.1 was less than a second longer than that of SUSE 10.1 at just below 8 seconds. Once again, the results are very good and better than those of all of the Windows NT series, as well as one of the best from other Linux versions, too. This creates another "sweet spot" of the benchmark - openSUSE 11.1, from the systems tested in the benchmark, is the fastest-booting relatively modern operating system.
The halt time of openSUSE 11.1 has improved considerably and is down to the Slackware 7.1 levels being just below 8 seconds, possibly due to a better way of handling the shutdown procedure.
Windows 7
RAM amount |
? MiB |
Release date |
2009 07 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
Windows NT 6.1 |
Enabled IO APIC |
True | Theme |
Classic |
Hard disk interface |
AHCI |
The installation media customisation step for Windows 7 is much less convenient compared to Windows Vista, as vLite does not support Windows 7. Instead, I had to use a tool called RT7Lite, which is slower, less convenient and less professional, but at least it does the job well. As a side note, there is another installation media customisation tool in the works right now, but it's not yet ready for daily use.
Aside from the program used to customise the installation, the installation process itself is virtually the same as it was in Windows Vista. Post-installation configuration that was carried out is also the same as in Vista - remaining unneeded services were disabled and all of the settings were set to Performance in its Advanced system options dialog.
But even with all the tweaks applied, the boot speed of Windows 7 stays underwhelming. It took over 26 seconds to boot the system. That is too long for comfort. Also, this is one of the worst results from all of Windows, with only Windows 2000 being slower (and Windows 8 CP, but more on that later). Ans the only Linux release tested in this benchmark that was slower than Windows 7 to boot was the evidently buggy Debian 2.0 "Hamm".
It's a similar story with halt times. While nine and a half seconds is not uncomfortable by itself (especially given that halt times are usually not as important as boot times, except when rebooting), it is nonetheless the longest halt time of all the tested Windows releases. When compared to Linux, only four of the tested systems (from Slackware 8.0 to SUSE 10.1) performed worse.
Overall Windows 7 fared very poorly in the test. The reasons for that are probably attributable to the size of the system - the larger it is, the longer it takes for the disk to read all the required files. Probably on an SSD the results would have been different.
openSUSE 12.2
RAM amount |
? MiB |
Release date |
2012 09 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
? |
Enabled IO APIC |
True | Graphical server |
X.Org ? |
Hard disk interface |
AHCI | Window manager |
twm |
Just like in the previous version of openSUSE, there is little difference in the installation steps, as the same system is used. Just like before, only minimal packages were installed, and any unnecessary daemons were disabled.
However, looking at the test results, it is obvious that there has been a regression, as the boot time is now up to the levels seen in Windows Vista, at 18 and a half a second. That is twice the time the last tested release needed!
On the other hand, we can see a very nice improvement in halt times. On average, it was around 5 seconds, which is pretty much on par with Windows XP x64. Also, if you look at the graph, you can see that there was a lot of variance in halt times.
The speed changes from the last release are quite obvious, and result in both good and bad things. It is most likely that the changes are due to the fact that openSUSE adopted systemd as the boot daemon as opposed to legacy SysVInit. It seems that the boot speed took a hit with it, although I am not certain why. It could be an interesting thing to investigate using bootchart and such.
Decrease in halt time and the large variance seems to suggest that systemd has a smart way of halting the system without any forced waiting, although it still waits for any running processes to finish their tasks.
Windows 8 Consumer Preview
RAM amount |
? MiB |
Release date |
2012 02 |
---|---|---|---|
Enabled cores |
4 | Kernel version |
Windows NT 6.2 |
Enabled IO APIC |
True | Theme |
Default |
Hard disk interface |
AHCI |
And lastly I also took Windows 8 Consumer Preview for a spin, but note that these results are in no way representative of the final product! The boot times will most likely be different on the release to manufacturing version of the OS.
Since Windows 8 is brand new and not yet stable (the latest one when the benchmark was carried out was the Consumer Preview), there are no tools to configure its image. Thus I had to install it with the stock configuration.
The installation procedure of Windows 8 is a bit different from its predecessors, but mostly in terms of user interface. It still won't allow to selects components not to install.
After installation, I disabled all of the unnecessary services manually, as well as removed all of the components that were offered for removal by the "add/remove system components" task. I also chose all of the graphical settings to be set to Performance. Interestingly enough, disabling themes in Windows 8 CP does not in fact turn on the classic theme, but rather the default stays on.
I also added the "command prompt" application to autostart (via the "startup" folder in the "start menu" folder). However, it appears that the autostart feature, while still working, is buggy in that it only starts the application a long time after boot. Since that was standard procedure, I counted the whole time until the terminal window appeared, so the actual time to boot would be lower if one was not to choose an application to autostart.
Another thing worth mentioning is that Windows 8 has the Metro UI set as the default shell. Normally it could even make a positive difference on a test like that, but it appears that the command prompt window is a window, and not a tile in Metro, so launching that also makes the system launch the whole "desktop" shell, which obviously slows it down.
All that and the fact that Windows 8 is larger than its predecessors (especially since there was no way to trim it down before install) makes it not that surprising to see that Windows 8 CP boot time is abysmal. More than 38 second boot time is simply unacceptable, and the only other OS in the test that fared worse was the buggy Debian 2.0 "Hamm", and only then by a single second.
On the other hand, the halt speed has increased considerably compared to the previous releases. Just below 4 seconds, it is in line with 32-bit Windows XP.