Info only re windows fast start

After reading something about Windows fast start here on the newsgroups
I got Curious and decided to run a few tests and see if it was worthwhile
First thing I found was that you must have hiberfile turned on to use
it, Oh, Oh.
So I turned it on for the test and here are my results.

Before
My boot time from switch on to desktop, 39 seconds, average of five runs.
Shutdown time 19 seconds average of five runs.

After.
With Fast start and hiberfile turned on.
My boot time From switch on to desktop, 37 seconds, Average of five runs.
Shutdown time 19 seconds average of five runs.

So, fast start gave me a gain of 2 seconds at a cost of a 5.57 GB hiberfile.

Kicked out hiberfile for good again and poured the snake oil down the
drain. :-)

Rene

On 8/28/19 2:52 PM, Rene Lamontagne wrote:
After reading something about Windows fast start here on the newsgroups
I got Curious and decided to run a few tests and see if it was worthwhile
First thing I found was that you must have hiberfile turned on to use
it, Oh, Oh.
So I turned it onÂ* for the test and here are my results.

Before
My boot time from switch on to desktop, 39 seconds, average of five runs.
Shutdown time 19 seconds average of five runs.

After.
With Fast start and hiberfile turned on.
My boot time From switch on to desktop, 37 seconds, Average of five runs.
Shutdown time 19 seconds average of five runs.

So, fast start gave me a gain of 2 seconds at a cost of a 5.57 GB
hiberfile.

Kicked out hiberfile for good again and poured the snake oil down the
drain.Â* :-)

Rene

I think that's what I would have done.

Wow, 39 seconds is better than mine. That "to desktop" is that with
everything loaded? I get a desktop but one drive and google drive
haven't loaded yet, nor my desktop calendar (Rainlendar) and widgets
(Rainmeter). So a lot goes on after I get a desktop before I'm
totally up and running.

Al

On 2019-08-28 2:45 p.m., Big Al wrote:
On 8/28/19 2:52 PM, Rene Lamontagne wrote:
After reading something about Windows fast start here on the
newsgroups I got Curious and decided to run a few tests and see if it
was worthwhile
First thing I found was that you must have hiberfile turned on to use
it, Oh, Oh.
So I turned it onÂ* for the test and here are my results.

Before
My boot time from switch on to desktop, 39 seconds, average of five runs.
Shutdown time 19 seconds average of five runs.

After.
With Fast start and hiberfile turned on.
My boot time From switch on to desktop, 37 seconds, Average of five runs.
Shutdown time 19 seconds average of five runs.

So, fast start gave me a gain of 2 seconds at a cost of a 5.57 GB
hiberfile.

Kicked out hiberfile for good again and poured the snake oil down the
drain.Â* :-)

Rene

I think that's what I would have done.

Wow, 39 seconds is better than mine.Â* That "to desktop" is that with
everything loaded?Â* I get a desktop but one drive and google drive
haven't loaded yet, nor my desktop calendar (Rainlendar) and widgets
(Rainmeter).Â*Â*Â* So a lot goes on after I get a desktop before I'm
totally up and running.

Al

Desktop with all it's icons appearing, no extras loaded.

Rene

Rene Lamontagne wrote:

After reading something about Windows fast start here on the
newsgroups I got Curious and decided to run a few tests and see if it
was worthwhile First thing I found was that you must have hiberfile
turned on to use it, Oh, Oh. So I turned it on for the test and here
are my results.

Before My boot time from switch on to desktop, 39 seconds, average of
five runs. Shutdown time 19 seconds average of five runs.

After. With Fast start and hiberfile turned on. My boot time From
switch on to desktop, 37 seconds, Average of five runs. Shutdown time
19 seconds average of five runs.

So, fast start gave me a gain of 2 seconds at a cost of a 5.57 GB
hiberfile.

And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.

https://www.tenforums.com/attachment...hybridboot.png

If you are using an SSD for the OS/app partition(s), there is a trivial
advantage (and bigger disadvantages) to using Fast Start. System
initialization will be lightning fast with an SSD, so you save little
boot time replacing it by loading a memory image (which still must be
read from a file). Services load concurrently (except for those that
are dependent on others) and can even overlap startup programs.
Initializing the hardware with a real boot and then initializing drivers
starts from a known start for the hardware. Fast Start just does the
driver loading but the hardware may not be in a known starting state
resulting in hardware malfunction.

The chart above attempts to exaggerate the boot time saving of Fast
Start by stretching the section for system initialization. The chart
(and its article) do not illustrate the differences in those boot
processes when using different types of storage media: slow vs fast HDD,
hybrid HDD+SSD, or SSD (and SATA3 vs NVM3 SSD), or even account for
differences in data bus bandwidth in the mobo design or effect of slow
vs fast CPUs.

Kicked out hiberfile for good again and poured the snake oil down the
drain. :-)

As I recall for my hardware setup, enabling Secure Boot mode in the UEFI
disabled Fast Start in Windows. Guess they're not compatible, or
there's a known vulnerability to circumvent Secure Boot by sliding in a
different hiberfil.sys file to present a different-than-expected image
when you startup again. Secure Boot was an attempt to regulate which
operating system(s) were allowed to load. Well, hiberfil.sys is an
image of the memory of the OS that gets reloaded when you restart
Windows, so why couldn't malware slide in a different hiberfil.sys file
or patch it? How is that file protected against malicious substitution?

https://www.blackhat.com/presentatio...ibernation.pdf
"Modified code can be executed!!"

Using hiberfil.sys to boot into an OS image is not different than the
old trick of booting from an optical drive (CD/DVD/BD) to load whatever
OS you want.

https://www.darknet.org.uk/2008/05/s...ernation-file/
Read and write the hibernation file.

In addition, it has been documented that Fast Start can cause data or
file system corruption, especially in multi-boot scenarios (i.e., Linux
+ Windows).

http://www.h-online.com/open/feature...k-1780640.html

Fast Start also makes it a bitch to boot into the UEFI/BIOS. You can no
longer interrupt the boot process by hitting F5 or F8. Instead you need
to use a program (e.g., RestartToUEFI) when already in Windows to reboot
to get into the UEFI to make changes to the system settings. There are
other workarounds but they're all clumsy compared to just hitting a key
during boot to get into the UEFI.

Also remember that a hibernation file must get saved on shutdown. So,
maybe just a little there is a faster startup but then add in the extra
time to shutdown. You gain on one end, lose on the other, the overall
effect is you gained little or nothing. You said it didn't take any
longer to shutdown with hibernation enabled or disabled. That doesn't
make sense. Fast Start is a hybrid hibernation mode, and that means
having to write to the hiberfil.sys file. With hibernation off, there's
no writing to hiberfil.sys on the shutdown. I can't see how writing a
hibernation file takes zero time.

On 2019-08-28 6:09 p.m., VanguardLH wrote:
Rene Lamontagne wrote:

After reading something about Windows fast start here on the
newsgroups I got Curious and decided to run a few tests and see if it
was worthwhile First thing I found was that you must have hiberfile
turned on to use it, Oh, Oh. So I turned it on for the test and here
are my results.

Before My boot time from switch on to desktop, 39 seconds, average of
five runs. Shutdown time 19 seconds average of five runs.

After. With Fast start and hiberfile turned on. My boot time From
switch on to desktop, 37 seconds, Average of five runs. Shutdown time
19 seconds average of five runs.

So, fast start gave me a gain of 2 seconds at a cost of a 5.57 GB
hiberfile.

And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.

https://www.tenforums.com/attachment...hybridboot.png

If you are using an SSD for the OS/app partition(s), there is a trivial
advantage (and bigger disadvantages) to using Fast Start. System
initialization will be lightning fast with an SSD, so you save little
boot time replacing it by loading a memory image (which still must be
read from a file). Services load concurrently (except for those that
are dependent on others) and can even overlap startup programs.
Initializing the hardware with a real boot and then initializing drivers
starts from a known start for the hardware. Fast Start just does the
driver loading but the hardware may not be in a known starting state
resulting in hardware malfunction.

The chart above attempts to exaggerate the boot time saving of Fast
Start by stretching the section for system initialization. The chart
(and its article) do not illustrate the differences in those boot
processes when using different types of storage media: slow vs fast HDD,
hybrid HDD+SSD, or SSD (and SATA3 vs NVM3 SSD), or even account for
differences in data bus bandwidth in the mobo design or effect of slow
vs fast CPUs.

Kicked out hiberfile for good again and poured the snake oil down the
drain. :-)

As I recall for my hardware setup, enabling Secure Boot mode in the UEFI
disabled Fast Start in Windows. Guess they're not compatible, or
there's a known vulnerability to circumvent Secure Boot by sliding in a
different hiberfil.sys file to present a different-than-expected image
when you startup again. Secure Boot was an attempt to regulate which
operating system(s) were allowed to load. Well, hiberfil.sys is an
image of the memory of the OS that gets reloaded when you restart
Windows, so why couldn't malware slide in a different hiberfil.sys file
or patch it? How is that file protected against malicious substitution?

https://www.blackhat.com/presentatio...ibernation.pdf
"Modified code can be executed!!"

Using hiberfil.sys to boot into an OS image is not different than the
old trick of booting from an optical drive (CD/DVD/BD) to load whatever
OS you want.

https://www.darknet.org.uk/2008/05/s...ernation-file/
Read and write the hibernation file.

In addition, it has been documented that Fast Start can cause data or
file system corruption, especially in multi-boot scenarios (i.e., Linux
+ Windows).

http://www.h-online.com/open/feature...k-1780640.html

Fast Start also makes it a bitch to boot into the UEFI/BIOS. You can no
longer interrupt the boot process by hitting F5 or F8. Instead you need
to use a program (e.g., RestartToUEFI) when already in Windows to reboot
to get into the UEFI to make changes to the system settings. There are
other workarounds but they're all clumsy compared to just hitting a key
during boot to get into the UEFI.

Also remember that a hibernation file must get saved on shutdown. So,
maybe just a little there is a faster startup but then add in the extra
time to shutdown. You gain on one end, lose on the other, the overall
effect is you gained little or nothing. You said it didn't take any
longer to shutdown with hibernation enabled or disabled. That doesn't
make sense. Fast Start is a hybrid hibernation mode, and that means
having to write to the hiberfil.sys file. With hibernation off, there's
no writing to hiberfil.sys on the shutdown. I can't see how writing a
hibernation file takes zero time.


I don't Know either but I timed it very carefully over 5 trials, Got the
same 19 seconds in both cases.
Yes I am using an M.2 NVMe drive as my boot and OS drive, It benches
3450 read and 2375 write in Crystaldisk 6.0 so that may make a difference.
Another great feature of the Last 3 Asus boards I have is that you
don't have to hit the delete or F8 key to get into the UEFI bios or boot
menu, Just hold the key down during boot and it goes into the bios or
boot menu automatically, it never misses, A godsend with these fast M.2
NVMe drives, This seems to be built into all Asus boards for the last 9
or 10 years.

Rene

In article , VanguardLH
wrote:


And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.

hard drives don't last forever either and they're far more likely to
fail than an ssd, which will normally outlast the device it's in.

On 29/08/2019 05:13, nospam wrote:
In article , VanguardLH
wrote:


And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.

hard drives don't last forever either and they're far more likely to
fail than an ssd, which will normally outlast the device it's in.

What is the best way of getting an 'early warning' of the imminent
failure of both a hard drive and an ssd?

On 2019-08-29 12:13 a.m., nospam wrote:
In article , VanguardLH
wrote:


And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.

hard drives don't last forever either and they're far more likely to
fail than an ssd, which will normally outlast the device it's in.

I wouldn't trust a hard disk at all nowadays. The last one internal one
I purchased, a WD Blue 2.5" one, last about 8 months. I knew that I
could send it in for warranty but I was looking to get rid of the laptop
it was in anyway and couldn't be bothered. Total crap to say the least.

On 2019-08-29 2:52 a.m., ~BD~ wrote:
On 29/08/2019 05:13, nospam wrote:
In article , VanguardLH
wrote:


And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.

hard drives don't last forever either and they're far more likely to
fail than an ssd, which will normally outlast the device it's in.

What is the best way of getting an 'early warning' of the imminent
failure of both a hard drive and an ssd?

Windows isn't very good at warning people from what I've seen
personally. Linux and its Gnome Disks application will be much more
efficient at letting you know about bad sectors which generally indicate
that the disk is on its last legs.

Rabid Robot wrote:
On 2019-08-29 2:52 a.m., ~BD~ wrote:
On 29/08/2019 05:13, nospam wrote:
In article , VanguardLH
wrote:

And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.
hard drives don't last forever either and they're far more likely to
fail than an ssd, which will normally outlast the device it's in.
What is the best way of getting an 'early warning' of the imminent
failure of both a hard drive and an ssd?

Windows isn't very good at warning people from what I've seen
personally. Linux and its Gnome Disks application will be much more
efficient at letting you know about bad sectors which generally indicate
that the disk is on its last legs.


One version of Windows 10, *did* start intercepting SMART info.
It buggered up the Health tab in HDTune as a result.

Whatever they were doing (or thought they were doing),
they've stopped doing it again.

*******

While SMART is better than nothing, waiting for a "calculated
value of disk isn't healthy", is waiting until it's too late.
I would not trust my disk drives to some "automation" determination
that I need to change disks right away.

I use the disk read transfer curve, as an early indication of
trouble. It starts to show signs of trouble, before the
reallocated raw indicator goes non-zero. Reallocated is
thresholded, to prevent cherry-picking disk drives when
they're brand new. There could be hundreds of thousands
of reallocations, before the Reallocated indicator
goes non-zero in the Raw field.

Basically, if you're oblivious to hardware (that "clicking noise"
the drive is making right now, doesn't bother you), and you don't
make regular backups, there *will* be data loss. The software
I've seen that uses the SMART data to compute a trouble
threshold, that's not sensitive enough.

The BIOS also has a warning capability, and the more modern
BIOS setup screens have a setting so that the boot will stop and a
notation will appear on the screen. I've *never* seen
that notation. Not once. It's pretty hard to get a
broken drive in just the right state, to test stuff like
this. My 500GB drives with the Reallocation problem,
don't trigger that warning. Not yet at least.

Paul

On 2019-08-29 10:42 a.m., Paul wrote:
Rabid Robot wrote:
On 2019-08-29 2:52 a.m., ~BD~ wrote:
On 29/08/2019 05:13, nospam wrote:
In article , VanguardLH
wrote:

And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.
hard drives don't last forever either and they're far more likely to
fail than an ssd, which will normally outlast the device it's in.
What is the best way of getting an 'early warning' of the imminent
failure of both a hard drive and an ssd?

Windows isn't very good at warning people from what I've seen
personally. Linux and its Gnome Disks application will be much more
efficient at letting you know about bad sectors which generally indicate
that the disk is on its last legs.


One version of Windows 10, *did* start intercepting SMART info.
It buggered up the Health tab in HDTune as a result.

Whatever they were doing (or thought they were doing),
they've stopped doing it again.

*******

While SMART is better than nothing, waiting for a "calculated
value of disk isn't healthy", is waiting until it's too late.
I would not trust my disk drives to some "automation" determination
that I need to change disks right away.

I use the disk read transfer curve, as an early indication of
trouble. It starts to show signs of trouble, before the
reallocated raw indicator goes non-zero. Reallocated is
thresholded, to prevent cherry-picking disk drives when
they're brand new. There could be hundreds of thousands
of reallocations, before the Reallocated indicator
goes non-zero in the Raw field.

Basically, if you're oblivious to hardware (that "clicking noise"
the drive is making right now, doesn't bother you), and you don't
make regular backups, there *will* be data loss. The software
I've seen that uses the SMART data to compute a trouble
threshold, that's not sensitive enough.

That clicking noise you're referring to is generally when I know that
I'm about to lose everything. Of course, that last 2.5" laptop HD didn't
even click for me; it just froze the system one day and refused to ever
boot into it again. Basically, the system was OK, then started to really
extremely slow and then froze to the point of becoming a brick and every
attempt to access the HD from that point on failed miserably. I'd never
seen anything die like that before, especially not after no more than
eight months.

The BIOS also has a warning capability, and the more modern
BIOS setup screens have a setting so that the boot will stop and a
notation will appear on the screen. I've *never* seen
that notation. Not once. It's pretty hard to get a
broken drive in just the right state, to test stuff like
this. My 500GB drives with the Reallocation problem,
don't trigger that warning. Not yet at least.

I just think it's safer to buy SSDs from this point on and never look
back at HDs. Even SSDs have sufficient storage for a good price so that
excuse is worthless for those who claim that they _need_ 8TB or
whatever. I've yet to see any of my SSDs fail and their performance is
top notch to this day.

On 29/08/2019 16:58, Rabid Robot wrote:

snipped all interesting information, although read!

My thanks to both RR and to Paul for your responses.

Much appreciated. :-)

--
David B.
Devon

Rene Lamontagne wrote:
After reading something about Windows fast start here on the newsgroups
I got Curious and decided to run a few tests and see if it was worthwhile
First thing I found was that you must have hiberfile turned on to use
it, Oh, Oh.
So I turned it on for the test and here are my results.

Before
My boot time from switch on to desktop, 39 seconds, average of five runs.
Shutdown time 19 seconds average of five runs.

After.
With Fast start and hiberfile turned on.
My boot time From switch on to desktop, 37 seconds, Average of five runs.
Shutdown time 19 seconds average of five runs.

So, fast start gave me a gain of 2 seconds at a cost of a 5.57 GB hiberfile.

Kicked out hiberfile for good again and poured the snake oil down the
drain. :-)

What's all this boot non-sense!? :-)

But seriously, I just Hibernate instead of Shutdown. Yes, that
requires a hiberfil.sys file, big beep deal.

After Hibernate, a wakeup is much, much faster than a boot. The
Hibernate itself costs more time than a Shutdown (because the memory
content has to be written to the hiberfil.sys file). Who cares? A
properly configured system will just switch itself off after the
Hibernate, so any 'waiting' is just imaginary.

In the very old days, one 'needed' to regularly reboot a system to
'clean' it up. For real OSs, those days are decades (for me nearly five)
ago and while Windows is not the most sturdy of OSs, it isn't *that*
much of 'a piece of crap'.

FWIW, as usual my system has not been rebooted since (the day after)
Patch Tuesday, i.e. 15 days.

On Thu, 29 Aug 2019 09:52:30 -0400, Rabid Robot wrote:

On 2019-08-29 12:13 a.m., nospam wrote:
In article , VanguardLH
wrote:


And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.

hard drives don't last forever either and they're far more likely to
fail than an ssd, which will normally outlast the device it's in.

I wouldn't trust a hard disk at all nowadays. The last one internal one
I purchased, a WD Blue 2.5" one, last about 8 months. I knew that I
could send it in for warranty but I was looking to get rid of the laptop
it was in anyway and couldn't be bothered. Total crap to say the least.

I always try to buy the WD 'black' drives with a 5yr guarantee.

--


Eric Stevens

There are two classes of people. Those who divide people into
two classes and those who don't. I belong to the second class.

Eric Stevens wrote:
On Thu, 29 Aug 2019 09:52:30 -0400, Rabid Robot wrote:

On 2019-08-29 12:13 a.m., nospam wrote:
In article , VanguardLH
wrote:

And remember, if you are using an SSD, that those writes to the
hiberfil.sys are on your SSD which has a limited number of writes.
hard drives don't last forever either and they're far more likely to
fail than an ssd, which will normally outlast the device it's in.
I wouldn't trust a hard disk at all nowadays. The last one internal one
I purchased, a WD Blue 2.5" one, last about 8 months. I knew that I
could send it in for warranty but I was looking to get rid of the laptop
it was in anyway and couldn't be bothered. Total crap to say the least.

I always try to buy the WD 'black' drives with a 5yr guarantee.


They keep juggling the drive level behind those colors.
You should take the designation as such, with a grain of salt.

It really is a treacherous world we live in.

http://forums.storagereview.com/inde...ck-wd4005fzbx/

And a lubricant excuse ? WTF??? Why do you need to drop
the flying height, to make a 4TB drive ? 4TB drives were
"perfected" years ago. You don't need to ruin them.

This is why you *cannot* keep buying the same color.
Because they keep ruining them.

Sometimes, the drive size matters. The 6TB may be a superior
product to the 4TB or 2TB models. Even though you may not want
6TB of capacity, maybe you get a better design that way.

Just about every time I've read the customer reviews, I've discovered
reasons to not buy certain stuff. The above thread is an example,
a warning of sorts. Now, I couldn't buy one of those 4TB ones.
Some other WDC products, that normally spin 24/7, the newer
models use "fast sleep" and it's like having a laptop drive
in your desktop. (You're all the time "waking it up".)
That's not why we pay a premium for those things. We
expect them to remain spinning and ready to go, and
not be messing around.

I have a 500GB drive with 47000 hours on it, that never
stops spinning or parking the heads. It still has spotless
SMART statistics too. It is possible for a drive to last
for a long time... When you find a unit that works that
well, it's like winning the lottery.

Paul