Intel Slashes Computer Startup Times

An anonymous reader writes "At Intel's Developer Forum in Taiwan, Intel introduced a new Non-volatile caching technology called 'Robson'." The new Robson cache technology allows computers to start up almost immediately and load programs much faster. Intel declined to comment on the specifics of how the technology works only saying that 'More information will be revealed later'.

We've had this tech for a while...

[thepotoo]

...it's called hibernate.

Seriously. My 1ghz, 256mb RAM laptop can turn off, "caching" the data in about 4 seconds, and start up in about 8.

If that's not good enough, try my 2.93ghz/1g RAM gaming desktop - 7 seconds for a clean start up (no hibernate).

Besides, who actually shuts down their computers any more? I mean, with more people using bittorrent at night, or just turning off monitors, I don't really worry about start up times. Do you?

DOH!

[Spy der Mann]

From TFA:

"Chipmaker demonstrates 'Robson' flash memory to boost laptop startup speeds."

Mystery solved.

Re:We've had this tech for a while...

[Chirs]

7 seconds from the time you hit the power button until you can start up applications? I call BS.

Re:Slightly OT question about linux boot times

[mrMango]

Look into ifplugd. emerge ifplugd.

Also, try using the ~x86 baselayout... they've GREATLY improved things from the standard.

Yes, this is OT

Re:Slightly OT question about linux boot times

[Anonymous Coward]

add '-t 10' to the dhcpcd options in conf.d for the interface. That will cause it to timeout in 10 seconds. You shouldn't need more than 10 seconds in my experience.

Re:Boot times

[amadeusb4]

To reduce boot, login and shutdown times, upgrade to Tiger (10.4). Here are times for mine(PB G4 with 768MB running 10.4.0):

• boot to login = 29 sec.
• login = ~25 sec (extended by startup items like iCal and stickies)
• shutdown = 11 sec

These numbers are a huge improvement to 10.3.9 running on my cube but then again the cube is nearly 5 years old.

Regarding the non-volatile booting, I would like to point out that my C-64 was already doing that.

Re:I hope this is real

[AuMatar]

Most of the boot time of a camera isn't memory loading, its hardware initialization and calibration.

Re:Boot times

[nick this]

Yes... osx boot times completely suck. That's why I only reboot after updates.

Time from opening lid of powerboot to idle desktop: 2-3 sec.
Time from closing lid of powerbook to glowing white "sleep" light: 4-5 seconds, but doesn't much matter.

I wouldn't want to be called an apologist or anything, but my laptop seems *way* faster to me than my xp box, just because my pb is essentially instant-on, what with the quick sleep times. It is annoying when you have to do a full boot though. Although 10.4 is some better in this regard than 10.3. Guess it's dictated by usage. Perhaps they spent time optimizing sleep times, not boot times, in that they expected people to sleep more often. Dunno.

Re:If they just took the crap out...

[NotAnotherReboot]

Someone feel free to correct me if I'm wrong, but Acrobat 7 finally fixed the issue of loading a bazillion plugins at startup that almost no one uses. I believe it now dynamically loads them as needed.

Load times for Acrobat 7 vs. Acrobat 6 are clearly far less. The fix often mentioned is to delete/move non-key plugins from the Acrobat plugin folder, but their solution finally fixes the problem in an elegant way.

Re:Boot times

[prockcore]

That's why I only reboot after updates.

I'm even worse. I tend to leave the Software Update "The new software requires your computer to reboot now" window sitting in background for days. Sometimes it stays open until Apple releases a new update that also need a reboot.

It's also the biggest reason I hate Safari... a browser update shouldn't require a reboot. WebKit shouldn't be that tied to the OS.

To the OP - misunderstanding cameras, Doh! etc.

[new500]

You complain about the zoom extending. Uhu, have you looked at compact multi-element zoom designs? 12 or more elements, many or even most of which geared independantly is not uncommon. The longer the zoom - comsumer guys want optical 10 times zooms, which would be unheard of in a professional lens for many other considerations (predominantly aperture speed and distortion characteristics) and that means even more complicated designs, even allowing small lenses are easier and simpler to design. Now try shifting all those elements _accurately_ with a tiny low voltage low torque servo (see why it's low torque here - too fe2w turns possible in such a small space to get a focus throw long enough to try to do this quickly and accurately and repeatably*). This is why my piezo-wave-effect ring-motor driven Nikkor zoom is several times more expensive of itself than almost any digicam.

Got the idea?

To the above poster - i sure hope there's not much calibration going on when i boot my Nikon. Unless it's to compensate for working temperature effects, if i've spent time and effort having a lens tuned to how i like it (yes this doesn't just happen, it's common) i want it to be left alone at that spec. Now that even modest digicams such as the Fuji F10/11 boot instantly and respond extremely quickly, there's simply no excuse for slow electronics and (electronic) shutter save at the real budget segment.

* even some (sadly many) professional photogs insist on continuing the myth that because the lens / sensor is small, everything remains sharp because the DOF (depth of field) is greater in those conditions. Er, DOF is a psychological effect which is a function of the print enlargement factor, print size, viewing distance and airy dic resolving limit - so the assumption is not true at equivalent apertures, hence the need even in very small "format" cameras to _still_ focus accurately, in OP's case, sadly, slowly too. The effect observed is anecdotally true however at small print sizes like 6" by 4".

Re:Hibernate

[morzel]

IIRC, hibernate is a wee bit smarter than that nowadays. (At least this is the case on Windows, don't know about the mechanism that is used on Linux or MacOS X).

Instead of just dumping the contents of the whole RAM to disk, it will only deal with the part of RAM that is actually allocated (not the part that is used as HD cache). For the actual memory that has been allocated, everything that can be paged to swap will be paged to the swap file. Due to the swapping mechanism, a great deal of the memory in use is probably already in the swap file. All the other bits are stored in a hibernation file.

When booting, all that has to be done is dump the contents of the hibernation file to RAM (which is probably way smaller than the actual size of the RAM). From that point on, the OS starts running again and pages the stuff you actually need back out of swap (a much more gradual process than dumping back a snapshot of the full RAM contents).

Re:To the OP - misunderstanding cameras, Doh! etc.

[new500]

I'll give you circuit cal. In particular i mentioned temperature calibration (a real issue for many photographics situations) But not in the way i specifically mentioned, which certainly wasn't a generic comment. "Light levels, color levels, gain, dc bias, etc" Of the first two on the list how on earth do you calibrate without reference sources? When i switch on my cam, it has a lens cap on and shutter closed, so that i guess allows the CD to reference a dark frame. However when i calibrate a (handheld) light meter, it's a process needing a reliable light source. Colorimeters/ spectros are beyond my capability to calibrate. But then i am talking reference calibration and you are i think talking about operating calibration. My point was, in this thread, and the context of the OP comment, that other factors outweigh calibration in terms of slowness in use. I am pretty sure that the tolerance of consumer users in photography to variations in output quality is vastly greater than minute variations in calibration. Thus i posit, toungue in cheek, that i wouldn't be surprised if 2/3 of the startup time wan't necessary at all :)

I wasn't arguing against your point, just suggesting alternatives as to why digicams can be slow to respond.

Re:What do you mean, "one can dream"?

[NMerriam]

you'd risk losing one of the prime reasons to use x86: compatibility. hell, motherboards still come with floppy connectors. why? because some ancient or niche programs still require a floppy to use. winxp still only accepts drivers for hd's on a floppy only.

Compatability is an illusion -- you can't install WinXP on a 16-bit processor, much less an 8-bit one. So why are the hardware limitations of XP systems still being driven by compatibility with 8-bit processors?

You actually point out a key difference in why the boot time is so screwed up on the PC. An ancient floppy connector and controller on the motherboard? Why? You can buy a $29.99 USB floppy drive and it will work perfectly on any modern PC motherboard. That technology is 10 years old. I mean, if you really want a 720k floppy drive hooked up, there's nothing in the MacOS hardware or software architecture that will stop you, Apple just recognizes that it's a waste of time to devote any of their own engineering effort or motherboard space to an obsolete technology. But if you install Darwin on an i386 system, it will quite happily find your 1987-era floppy and boot from it.

and frankly, the bios or initialization hardware shouldn't be doing much more than just probing the hardware and passing control to an OS

That's exactly what the Mac does, and exactly what the PC doesn't do. The PC hardware is still based around the 1980s notion that you would have certain predictable and limited peices of hardware that meet certain outdated specifications and the BIOS would control them all. We've been building workarounds for that assumption and it's arbitrary limitations (640k of memory? Boot past a certain cylinder on the hard drive?) ever since.

Welcome to the Macintosh.

[Anonymous Coward]

Pro-tip.

Never turn your powerbook off.

Re:Boot times

[aleander]

If it's anything similiar to Linux or Windows, then WebKit does not need to be tied to the OS. AFAIR it's a library and there can be more than one application running that uses it. If there's an e.g. security problem, then it is essential to replace all running instances of it with the new version, and rebooting the computer is the simpliest way of assuring this.

Re:I hope this is real

[bezza]

Anandtech did a review on Gigabyte's i-RAM product that is available now. Basically it takes 4GB of DDR DRAM and treats it like a SATA drive. Booting windows from this yielded no speed up, generally because most of the time was spent waiting for hardware to initialise.

The review is here [anandtech.com]

Re:If this kind if thing is a concern

[neurovish]

A large part of the problem is Win2k..XP boots up much faster.
Linux boot times depend largely on the distribution...my Gentoo box at home boots up in about 20 seconds, and the same goes for Slackware. At work however, Novell's linux flavor du jour (SuSE, NLD, or SLES) takes a good 2 minutes. My work desktop boots into XP much faster than Novells Linux.

Re:Has anyone RTFA?

[swillden]

Happening right now, search for "init-ng". It apparently works well but is still under heavy development so it's not stable enough to include in any mainstream distro.

Debian testing includes it. Not as the default option, but it's apt-get installable. I'm using it on my laptop and it's very nice.

Re:If this kind if thing is a concern

[quantum bit]

The difference is, in unix type systems, SIGTERM and SIGKILL are handled by the OS and the process is only informed of them (so it can try to shut down properly), in Windows, the process is being asked nicely to close. Windows process is free to ignore these events.

No, no, and no. It's true that in the "Tasks" or "Applications" tab, hitting End Task will send a request (WM_QUIT) to exit. That's not what I'm talking about. I mean the Processes tab. That is handled by the OS; it routes through Win32 first but ends up at NtTerminateProcess (ZwTerminateProcess). Go read the API reference or even the DDK if you don't believe me. Maybe in the dark days of Win9x that was true, but the NT kernel is a real OS, no matter what other crap you layer on top of it.

There are only three states a process can be in where it's unkillable.

1. "Access denied". This happens on some system processes because they run as the user SYSTEM (equivalent to root), where your task manager process is not. The security descriptor on those processes is set so that nobody except SYSTEM (not even Administrators) can kill them. They can be killed by running task manager as SYSTEM. There are various methods to run a process under the system account; the easiest is by using the "at" command to have the scheduler service start it. Newer versions of task manager also have a list of processes it will refuse to kill, but you can still kill them by using pskill [sysinternals.com] or some other third-party utility that has no such restrictions.

2. Process is stuck in the kernel somewhere. Happens when system calls never return, which isn't supposed to happen. Often due to bad drivers -- even with flaky hardware it SHOULD timeout eventually. I've seen add-on firewall software that hooks the TCP stack and can cause this condition. Sometimes you can get one unstuck by kicking the kernel in the head (i.e. removing or stopping the offending device), otherwise a reboot is the only way to clear it. Unless you're running a checked build with a remote serial debugger, but not many people outside of driver developers do that.

3. Process has a debugger attached. In this case, simply kill the debugger instead.

Re:If this kind if thing is a concern

[quantum bit]

most remarkably virii and malware manage to get unkillable quite easily. Flaky security or the unability to chmod your stuff may have something to do with it.

A lot of malware isn't unkillable in the traditional sense. What it does is run 2 processes that act as a watchdog for each other. Kill one and the other one starts it back up. They probably got the idea from MS even -- back in the day Windows used two system threads that watched out for each other and kept you from tweaking the registry key to turn NT Workstation into NT Server [oreilly.com].

A technique I like to use for killing those is to find the EXE file that is being re-launched every time you kill it. You won't be able to delete it because of Win32's breaindead filesystem semantics, but you can change permissions on it to deny access to everyone. Then when you kill one of the processes, the other one isn't able to start it back up. I've yet to see any malware smart enough to change permissions back on the file, so for now anyway it's an effective way to kill them.

Re:I hope this is real

[moro_666]

yeah, your notice is sad but true.

windows people are so fooled by the fast desktop picture, they dont realize that the system is dynamically still loading and just lagging behind, even if they get their windows picture up in 15 seconds, they still have to wait 20 seconds at least until they can really start to do just about anything.

windows doesnt start any faster than linux, the first image comes sooner and sadly most of the stuff is loaded under cover (bill's surprise), but if you have a sensible amount of stuff installed, linux boots way faster up to the moment when something can really be used by the user.