Linux can be so amazing when configured especially for some tasks. For example, Jack on linux can deliver audio latencies under 2ms! The problem is that configuring Linux like this almost requires a CS degree.
I once had a brief conversation (via Reddit) with a guy using JACK for a commercial (embedded Linux) networked audio system. I wasn't aware of the exact specifics but I understand it was Sonos-style, embedded boards inside speakers. He wasn't particularly interested in talking about the work his team had done :P
Also under 1 second, and the approaches this guy took are seriously impressive. Lots of educational tidbits and "good-to-know"s in here even for non-embedded types. Reads very quickly too.
1 seconds seems a rather arbitrary measure. In HCI 100ms seems to be the value that's generally taken under which an action seems to be happening instantaneously [1]
It's quite sad to see how we hardly use the computing power offered by our modern computers to actually speed up common tasks, but instead bloat it up with all kinds of stuff.
One second, ten seconds... The problem isn't that it takes time, it's that the user has to sit there and wait while it takes that time.
My desktop takes about two seconds to resume from suspend. I'd sit down, lean down to the floor and press the power button and then wait that two seconds. I fixed the whole problem by moving the case up onto the desk so that I have to walk past it to sit down. Now I press the button and then sit down, by which time the computer is waiting for me. The way it should be.
Sidebar: Now I'm slightly concerned that an AI in the future is going to call me out for my blatant display of meatbag privilege.
We can throw tons of money at engineering boot times but but really the biggest gains are made when you can predict what the user wants. Imagine you approach your car. If it can detect you or your key, it can start doing stuff it'd normally do when you put the key in the ignition. Suddenly it doesn't matter than it takes 5-10 seconds to boot because it also takes 10 seconds to get in the car.
All this stuff is going to get better once we have widespread adoption of technology for fine indoor tracking. When we can tell our relative positions to our gadgets, they'll be able to sleep deeper, ring louder, shine brighter and start booting earlier.
Same applies to Virtual Reality. You need sub 20ms latency for head tracking to eyes latency or you will feel sick (effectively less than 10ms from the cpu side. Display scanning is summed on top).
The 100ms figure applies mostly to traditional UI workflow. Whenever you need a realtime interaction that's 10x too high.
If you can boot faster than the screen can come to life, you don't need to be faster. IoT and servers might not have screens, so this doesn't apply to everything, but for devices with screens, just beating the screen warmup is good enough to feel like immediate startup.
Also, for devices that require user authentication, such as logging in to an account, if you could offload the authentication (such as fingerprint or other biometrics) to something out of the OS itself (ROM routine that starts up with a 0 in a certain memory address and changes it to 1 on authentication), you could be booting up the OS in the background while you take a second or two to log in, and if the OS can get up and running by the time you log in, the OS can pretend that it started up immediately and was the thing that logged you in. For many devices, there is need to boot up in less than a second or so to seem as though boot up was instantaneous.
Even that may be debunked it seems it's now down to 13ms and that number is only due to testing equipment limitations of 13ms. According to "Mary Potter, an MIT professor of brain and cognitive sciences and senior author of the study".
Comparing the richness of the user experience for a wide variety of applications of now versus a decade or two ago, I think we are doing plenty of useful things with modern systems that is not actually "bloat".
But 1s is sufficiently small so that you don't notice that the system is loading between the time you switch on the engine of a car and the time you start using it.
Was looking to boot to Qt under a couple of seconds for a camera use case a few months back, and came across similar demos. Can work well for very specific applications/products.
Here's a video of a talk by the author of this particular pdf
(the steady state is that computers are running, so if it takes 30sec to cleanly shutdown then your cycle time is 31secs... obviously, this doesn't apply to stateless servers or that use write-through caching...)
The kind of device this kind of optimization applies to typically runs with readonly flash, maybe only writing some config rarely... So, just pull the plug.
How much do you cache? Hardware is difficult because you could add/remove/swap it at any time, and software information is already partly cached depending on your OS.
IIRC, Windows a) builds a list of files to pre-load from disk based on your usage, and b) doesn't actually fully shut down by default (it goes to hibernate mode: http://blogs.msdn.com/b/olivnie/archive/2012/12/14/windows-8...). I don't know if any Linux distros do either of those by default, but it is certainly possible.
Also, some BIOSes already have a "quick boot" setting which caches some hardware information, particularly about memory. It usually comes with a warning that you need to disable the setting for at least one boot when installing RAM.
Hardware requires specific handshaking to get it to initialize, the kernel cannot assume that the hardware that was present last time is available this time, and orchestrating everything is not an easy process.
The holy grail would be a kernel organized and designed to cache everything to disk related to its own configuration, and only re-execute/rerun the hardware reinitialization code.
Admittedly, Windows' current approach to bootup is very close: it closes all applications then pseudo-hibernates the kernel. Bootup simply reads the hibernated kernel state from disk and reloads userspace.
This is of course besides traditional full ACPI hibernation, which is pretty cool but isn't a perfect art. (I'm typing this on a ThinkPad T23, a fairly old (and thus well-tested) hardware configuration; its hibernation/resume is usually rock-solid, but this morning my WLAN decided to get all stupid with dhcpcd, and USB decided that while it could see my external HDD, there wasn't a disk inside it. From-scratch boot is still the only way to get a reasonably predictable system state.)
The biggest problem with caching things during the boot process is that turning our devices off and on again will not magically solve our problems any more.
Our team was working on a vehicle telmatics platform ( connected cars ). We had a requirement in which the remote engine start time should be within 15 seconds from the time the customer clicked the start button on his phone. For this the QNX running in the vehicle had a fastboot mode , which came up within that timeframe , brought up the interfaces & established network connection to our server and started the car. Once the car is started , the system will go down and come back up in normal boot.
People are OK with frequently booting their mobile devices to temporarily "fix bugs", which can take up to tens of seconds, but waiting a moment to boot a desktop device? Nuh uh.
Of course there might be some market advantage to be had with faster booting and it's a plus for the whole UX. And optimisation is definitely cool, though I think many more problems would be solved if people were forced to think once in a while, whether it's while waiting for the bootup sequence to complete or a train to arrive.
Seems like this is more about car computers, embedded systems, and replacing "suspend" than just improving the desktop experience. The slowest booting machine I own is my windows Steambox, and it's still faster to boot than my TV or receiver (5-10 seconds) just by virtue of having an SSD.
The problem with a desktop is that most people have at least one and mostly several applications running. Those need maybe saving as well, before quitting. The mobile phones are better in that way: all apps are required to save their state at any time. So rebooting can be a mindless procedure.
[+] [-] nileshtrivedi|10 years ago|reply
[+] [-] rifung|10 years ago|reply
[+] [-] i336_|10 years ago|reply
I think that proves your point.
[+] [-] CyberDildonics|10 years ago|reply
[+] [-] RIMR|10 years ago|reply
[+] [-] i336_|10 years ago|reply
http://elinux.org/images/f/f7/RightApproachMinimalBootTimes....
Also under 1 second, and the approaches this guy took are seriously impressive. Lots of educational tidbits and "good-to-know"s in here even for non-embedded types. Reads very quickly too.
[+] [-] legulere|10 years ago|reply
It's quite sad to see how we hardly use the computing power offered by our modern computers to actually speed up common tasks, but instead bloat it up with all kinds of stuff.
[1] http://cogsci.stackexchange.com/questions/1664/what-is-the-t...
[+] [-] oliwarner|10 years ago|reply
My desktop takes about two seconds to resume from suspend. I'd sit down, lean down to the floor and press the power button and then wait that two seconds. I fixed the whole problem by moving the case up onto the desk so that I have to walk past it to sit down. Now I press the button and then sit down, by which time the computer is waiting for me. The way it should be.
Sidebar: Now I'm slightly concerned that an AI in the future is going to call me out for my blatant display of meatbag privilege.
We can throw tons of money at engineering boot times but but really the biggest gains are made when you can predict what the user wants. Imagine you approach your car. If it can detect you or your key, it can start doing stuff it'd normally do when you put the key in the ignition. Suddenly it doesn't matter than it takes 5-10 seconds to boot because it also takes 10 seconds to get in the car.
All this stuff is going to get better once we have widespread adoption of technology for fine indoor tracking. When we can tell our relative positions to our gadgets, they'll be able to sleep deeper, ring louder, shine brighter and start booting earlier.
[+] [-] sharpneli|10 years ago|reply
And it's actually even worse than that. 100ms is nowhere near enough to be sufficient for all applications.
For audio applications you need 10ms [http://superpowered.com/androidaudiopathlatency] which incidentally is the reason why Android is unusable for any interactive audio applications.
Same applies to Virtual Reality. You need sub 20ms latency for head tracking to eyes latency or you will feel sick (effectively less than 10ms from the cpu side. Display scanning is summed on top).
The 100ms figure applies mostly to traditional UI workflow. Whenever you need a realtime interaction that's 10x too high.
[+] [-] SiVal|10 years ago|reply
Also, for devices that require user authentication, such as logging in to an account, if you could offload the authentication (such as fingerprint or other biometrics) to something out of the OS itself (ROM routine that starts up with a 0 in a certain memory address and changes it to 1 on authentication), you could be booting up the OS in the background while you take a second or two to log in, and if the OS can get up and running by the time you log in, the OS can pretend that it started up immediately and was the thing that logged you in. For many devices, there is need to boot up in less than a second or so to seem as though boot up was instantaneous.
[+] [-] dghughes|10 years ago|reply
http://news.mit.edu/2014/in-the-blink-of-an-eye-0116
[+] [-] scott_s|10 years ago|reply
[+] [-] cm2187|10 years ago|reply
[+] [-] estomagordo|10 years ago|reply
[+] [-] weland|10 years ago|reply
[+] [-] dharma1|10 years ago|reply
Here's a video of a talk by the author of this particular pdf
https://www.youtube.com/watch?v=KTRA1PRJWH8
Will be interesting to see what impact Intel's 3D Xpoint will have on boot times too.
[+] [-] smcl|10 years ago|reply
[+] [-] asah|10 years ago|reply
(the steady state is that computers are running, so if it takes 30sec to cleanly shutdown then your cycle time is 31secs... obviously, this doesn't apply to stateless servers or that use write-through caching...)
[+] [-] cnvogel|10 years ago|reply
[+] [-] listic|10 years ago|reply
[+] [-] oblio|10 years ago|reply
TVs should be turned off completely when you press the button, to save power. After that almost all smart TV boot up quite slowly. Which is sad :(
[+] [-] kalleboo|10 years ago|reply
[+] [-] xanderstrike|10 years ago|reply
Rebooting your phone is an uncommon use case, so it's not optimized.
[+] [-] dharma1|10 years ago|reply
[+] [-] amelius|10 years ago|reply
[+] [-] psi-squared|10 years ago|reply
IIRC, Windows a) builds a list of files to pre-load from disk based on your usage, and b) doesn't actually fully shut down by default (it goes to hibernate mode: http://blogs.msdn.com/b/olivnie/archive/2012/12/14/windows-8...). I don't know if any Linux distros do either of those by default, but it is certainly possible.
Also, some BIOSes already have a "quick boot" setting which caches some hardware information, particularly about memory. It usually comes with a warning that you need to disable the setting for at least one boot when installing RAM.
[+] [-] i336_|10 years ago|reply
The holy grail would be a kernel organized and designed to cache everything to disk related to its own configuration, and only re-execute/rerun the hardware reinitialization code.
Admittedly, Windows' current approach to bootup is very close: it closes all applications then pseudo-hibernates the kernel. Bootup simply reads the hibernated kernel state from disk and reloads userspace.
This is of course besides traditional full ACPI hibernation, which is pretty cool but isn't a perfect art. (I'm typing this on a ThinkPad T23, a fairly old (and thus well-tested) hardware configuration; its hibernation/resume is usually rock-solid, but this morning my WLAN decided to get all stupid with dhcpcd, and USB decided that while it could see my external HDD, there wasn't a disk inside it. From-scratch boot is still the only way to get a reasonably predictable system state.)
[+] [-] rejschaap|10 years ago|reply
[+] [-] caf|10 years ago|reply
[+] [-] creshal|10 years ago|reply
[+] [-] blab3|10 years ago|reply
In the embedded hardware environment if something has changed and if this change is out of specs, then what you say can be adopted.
[+] [-] voltagex_|10 years ago|reply
[+] [-] ww520|10 years ago|reply
[+] [-] titomc|10 years ago|reply
Now I know !
[+] [-] PinguTS|10 years ago|reply
There is also some documentation from Montavista from that time.
EDIT: The presentation by Montavista from 2008: http://www.freescale.com/files/training_pdf/VFTF09_MONTAVIST...
[+] [-] nickpsecurity|10 years ago|reply
[+] [-] csn|10 years ago|reply
Of course there might be some market advantage to be had with faster booting and it's a plus for the whole UX. And optimisation is definitely cool, though I think many more problems would be solved if people were forced to think once in a while, whether it's while waiting for the bootup sequence to complete or a train to arrive.
[+] [-] geon|10 years ago|reply
[+] [-] xanderstrike|10 years ago|reply
[+] [-] Gys|10 years ago|reply
[+] [-] digi_owl|10 years ago|reply
[+] [-] vessenes|10 years ago|reply
[+] [-] __float|10 years ago|reply
[+] [-] pass-word|10 years ago|reply
[deleted]
[+] [-] daw___|10 years ago|reply