This seems to be a similar approach to the one taken by Windows[0]
There were a causes for the poor resume time, but a large contributor was device resume time. Since the OS serialized S0 IRPs to all devices in the PnP tree, the time for each device to resume added sequentially to the system's resume time.
The OS serialization of the S0 IRPs could not change for Windows XP, so the problem was attacked at the other end...each driver would complete the S0 IRP as fast as it could so the OS could resume quickly and then asynchronously power up the device.
This way each device could power up in parallel and the total time to power up was not sequential (nor was it only the longest of any device to power up since there is still ordering between parent and child devices) and resume time could be dramatically slower.
I switched from XP to Ubuntu about 6 years ago. At the time I was running an old dell laptop that had been shipped with XP. Perhaps their concept is similar, but my resume time in Ubuntu was a lot faster than that of XP.
Perhaps they had the right idea but didn't execute it perfectly, hopefully the Linux devs will get it right. I'm impressed by the resume times in windows 7 on faster computers but on more budget systems Linux still seems to be the king of resume times and performance (at least in my experience). I've only used windows 8 on an employees laptop and from what I can tell, it wasn't made to perform well on his Toshiba to say the least. I've seen both windows 7 and windows 8 running very well, much better than linux, on the right hardware though. The performance of windows on budget hardware (75% of consumer) is mediocre at best, which is unfortunate, but what's even more unfortunate is that because a select few can get Windows performing amazingly on great hardware, the consumer market seems to think it runs amazingly everywhere. Hopefully soon it will, or people will come to their senses and realize installing windows on a low budget (average consumer grade) system is more trouble than it's worth.
One thing I hate with my Mac is the window dressing they do, they show the screen as it was before it's actually usable to give an impression of faster resume than it really has.
It's good as an interface, I think, because the human also requires some startup time -- if you can see what the screen looks like before it is interactive, you can orient yourself while the machine finishes reactivating.
Indeed it's a very good thing, especially if the actual resume can happen in that time span.
Sometimes it's frustrating since it looks like frozen.
Sometimes it's misleading, e.g. when you see that you didn't get an email or a IM notification, and then you realize it's because your e-mail/IM app is not really running yet.
Or when you take a quick glance to the wifi indicator and see that there are many bars and then you go away assuming there is connectivity but when it actually awakes you are not really online.
Microsoft faked the startup speed beginning with WinXP too. In Windows 2000 it took a long time to see the desktop. To speed it up in WinXP they show the desktop quit early but several startup-processes are still running with higher priority. So you had to wait til the hour-class was gone and the UI reacted to mouse clicks. Well the same was true for earlier MacOS X like 10.4 Tiger were you could watch and wait the spinning ball.
Nowadays with multi-core CPUs and SSD you won't notice such effects.
Systemd on Linux now does the same thing. On an SSD, it is really fast. On an older hard drive with slow seek times, you get a bit of thrashing which causes the overall boot time to be a tad bit slower in some cases.
Hate? I like this feature for 2 reasons: the clock shows the time at which the computer suspended (gives me an indication of how many hours I've been asleep on the keyboard :)) and if I was reading something, I can keep reading it while the OS loads.
I use both OS X and Linux daily, each on laptops and I would have agreed with you until recently. On 3.12-3.14 my resume times on have gone from slower than OS X to at least as fast, sometimes apparently faster, than the same OS X laptop.
This is a pure btrfs, gnome, arch linux install. Old hardware (Thinkpad x220).
Notably OS X still brings networking back up faster, but that is in the pipeline already for Linux.
> Notable OS X still brings networking back up faster
With the notable point that it doesn't work properly on a lot of hardware, in my experience (and in the experience of others I know). The major ISP in ireland provides the same box for most connections, and my mac just will not hold a connection to them when resuming from sleep. It appears to be an issue revolving around assignment of IP addresses, but I can't reproduce it, and it doesn't happen on my work network or uni network, but every UPC network I use with the same equipment (Technicolor TC7200U) has the issue.
Offtopic: My cat opened the TC7200 accidentaly. There are two serial ports. One is easily reachable and gives access to the bootloader which lets you r/w memory (and jump to anything in memory).
The second one is under the cooler. <s>You</s> Your cat can easily solder <s>yourself</s> itself on it from the back of the pcb, if <s>you</s> your cat doesn't want to remove it. You'll see linux booting, you can login with your webinterface credentials, but it kicks you out immediately because you don't have a shell.
Just in case anyone want's to work on what my cat has discovered. It is leased with my ISP contract, so I would never open it myself.
Linux based? Well fuck Technicolor then, there's no mention of GPL source code... and I would not be surprised if it's U-boot based.
As for the "fuck" part, AVM with the Fritzbox ain't a bit better, though. Looks like all cable routers are locked down and no sources available - probably to prevent people from building DOCSIS sniffers or network disrupters (30-apartment house, all connected via DOCSIS on one link, now good luck finding the asshole).
A dead HN thread isn't the right place to do this. Contact me at hnlawl.tc7200 ãt dumbinter pẽriod net.
I've quickly googled a picture of the PCB for you and annotated it. From you thread you linked that's the bootloader serial port. if you look beneath the cooler (without removing it) you'll see "console" written there. That's the Linux serial console. I didn't want to remove the cooler. So my cat just soldered itself onto it from the back of the PCB. I'm not sure what the pinout was anymore. But it's easy enough to figure out with a multimeter.
Edit: I've made a picture, My cellphone cam sucks, but you can see the "CONSOLE" written on it. Just use a multimeter on the back of your PCB to figure out the pinout.
Also I did see the telnet port in the management net, but could figure out the login. The regular HTTP webinterface loads too on this ip, but you can't login with your credentials. If my create a backup from your config on the webinterface, there seems to be a user for ISP support at the end of the file. But I couldn't login with that either.
I have experienced the opposite with my MacBook Air.
I have a Asus RT ac 66u router and use 5ghz on both the air and my Acer Chromebook c720 with archlinux installed on it using NetworkManager.
The the MacBook Air takes about 6sec to connect to the wifi while my Chromebook takes less than 2 seconds. Both can load Internet pages instantly after the OS reports that it's connected.
I have no idea why the MacBook takes so long, but I recently did a fresh install on it and got the same results
How did you get suspend and resume running on the C720? I have a C720P and I've been trying to get it to resume at all(it freezes when I reopen the lid)
Slightly tangential, but I have almost the same setup (Arch + Thinkpad) and I've noticed slower shutdown times since ~3.12 due to systemd taking down oldroot. Are you experiencing the same thing?
I had a couple problems requiring a btrfsck, specifically related to google-chrome cache directories. Never had it since. I use btrfs snapshotting a lot (for convenient system rollback).
I definitely am not running btrfs on a production machine, but I love it on this laptop. Wouldn't call it stable yet.
Speed isn't the only consideration. If you're using disk encryption, the only way to remove keys from RAM is to power off or hibernate. Preserving state between sessions with hibernation is much more convenient. Also, Linux only uses RAM * 2/5 as the size of the hibernation image [1]. You can make this even smaller by changing /sys/power/image_size. So with 16GB of RAM, it only has to write/read about 6.4GB.
You can use LVM to make the swap partition inside the encrypted container. If you don't want to use LVM, you can just use a swap file on an encrypted partition (but this isn't supported with btrfs).
The data presented shows resume times like nothing I have experienced in years. I'm guessing that if you already have a SSD-enabled laptop, the improvements wont be that noticable.
Still: Good to see more and more subsystems moving to parallel/async initialization. Every measure counts, and together I'm certain they do add up.
Yes it has been merged, however given that the merge window only opened recently the 3.15 release will be 3-4 months away. Given that time frame its not likely that 3.15 will make it into the autumns Linux distribution releases. Probably be a year before this gets into the hands of users.
(unless someone backports it or you build your own kernel)
Suse tumbleweed, the Kernel Developers PPA, Debian Experimental / Unstable, Arch, Fedora Rawhide, and Gentoo all deliver new kernels usually within a month of release, most within days (albeit more buggy).
I seem to get kernel updates using Debian Unstable (I don't pay much attention; but my current kernel is 3.13 and I installed my current OS years ago) and I think Arch does too. I'm sure there's others.
There were a causes for the poor resume time, but a large contributor was device resume time. Since the OS serialized S0 IRPs to all devices in the PnP tree, the time for each device to resume added sequentially to the system's resume time.
The OS serialization of the S0 IRPs could not change for Windows XP, so the problem was attacked at the other end...each driver would complete the S0 IRP as fast as it could so the OS could resume quickly and then asynchronously power up the device.
This way each device could power up in parallel and the total time to power up was not sequential (nor was it only the longest of any device to power up since there is still ordering between parent and child devices) and resume time could be dramatically slower.
[0]http://blogs.msdn.com/b/doronh/archive/2007/10/15/fast-resum...