Windows Enterprise Client Boot and Logon Optimization – Part 4, An Aside on ReadyBoot


This post continues the series that started here.

During my last post, I discussed a benchmarking process you might use during the development of your Windows client system image. To recap –

Benchmarking-01

The piece that I didn’t discuss was Optimize ReadyBoot.

So What is ReadyBoot?

ReadyBoot has been around for a long while and was introduced to address Disk I/O bottlenecks. The idea is that the ReadyBoot driver pre-fetches data from disk ahead of when it’s needed and caches it in RAM. When it comes time for that data to be used, it’s available from RAM at low latency.

ReadyBoot

In order to fetch the right data at the right time, ReadyBoot builds a boot plan based on past experience. In other words, ReadyBoot pays attention to the data read by the system during past boot sequences and uses this information to pre-fetch data on the next boot. ReadyBoot also optimizes the location of this data on disk during scheduled disk defragmentation runs.

So Why Optimize ReadyBoot During the Benchmarking Process?

ReadyBoot takes time to optimize (a number of reboots and a defrag cycle). Installing Windows straight off distribution media and gathering a timing trace won’t accurately represent the system at its best performance.

Additionally, large changes to the system can mean the last boot plan is sub optimal. ReadyBoot usually tolerates small system changes but for example, installing Antivirus software which loads large virus definition files during boot will invalidate the boot plan.

What Happens When the Boot Plan is Suboptimal?

A suboptimal boot plan means that the right data is not pre-fetched at the right time and boot slows down.

Terminology that ties into the diagram above –

  • A Hit – A read request serviced by the ReadyBoot RAM cache
  • A Pend – A read request for data not already in the ReadyBoot RAM cache but scheduled for prefetching within the next 500 I/O’s
    • The requesting process will be blocked until the data is pulled into the cache
  • A Miss – A read request for data not already in the ReadyBoot RAM cache and not scheduled for prefetching within the next 500 I/O’s
    • I/O is sent directly to the disk, disrupting the pre-fetcher
    • High I/O pressure may result in the pre-fetcher failing to keep up

How Do I Manually Optimize ReadyBoot?

An additional tool is included with the Windows Performance Toolkit (WPT). XBootMgr.exe is the tool used to gather boot traces during early versions of WPT (it may still be used for this purpose but now you have WPRUI.exe).

You can trigger ReadyBoot optimization from an elevated command prompt (Run as Administrator) using

xbootmgr –trace boot –prepSystem –resultPath <path>

The <path> is used to store boot traces during the optimization process.

Executing this command will trigger a series of reboots that build a boot plan, defrag the hard drive and optimize ReadyBoot. It’s a time consuming operation and requires a logon after each reboot. It’s not uncommon for observers to think a system has hung during the defrag interval.

For these reasons, use ReadyBoot optimization cautiously; only after large changes to the system or when you see that ReadyBoot efficiency is dropping away.

How Do I Measure ReadyBoot Efficiency?

ReadyBoot efficiency data may be extracted from a timing trace. Just as we extracted boot timing information and trace statistics in Part 3 of this blog series, we can extract ReadyBoot information with

xperf -i <filename.etl> -o ReadyBootSummary.txt -a bootprefetch -summary

This time, the output is simple text and so we choose an output file with a .txt extension. Once collected, the output looks like

image

As mentioned in the graphic, you should aim for Prefetch-Hit Ratio and Request-Hit Ratio to exceed 80%.

Keep in mind that as more components are installed, more data may need reading from disk during boot. The longer the boot process goes, the more variance there may be in the boot sequence and an optimized boot plan may be harder to achieve.

How Does Hardware Effect ReadyBoot Efficiency?

CPU and disk speeds play a significant role and ReadyBoot can only achieve so much. If your system has a very high CPU speed but a very slow disk (e.g. 5400 RPM), pre-fetched data may be consumed before ReadyBoot can pre-fetch more, leading to a high miss ratio.

In general, more RAM offers ReadyBoot more cache and in turn, you should see better system performance during boot and logon.

In Part 3, I mentioned that you don’t need to optimize ReadyBoot if your system uses a Solid State Drive (SSD). SSDs are fast enough that there’s no significant benefit to using ReadyBoot and so, Windows disables the feature.

Conclusion

The first four posts of this blog series have introduced the idea of Windows Enterprise Client Boot and Logon Optimization. I’ve discussed tools and instrumentation you might use to trace and benchmark a system as a Windows client image is developed.

Finally in this post, I’ve discussed ReadyBoot functionality, when it’s important to optimize it and how do execute that optimization.

With the first four posts in this series, you should be empowered to design your Windows Enterprise Client system image with performance in mind.

Next Up

Windows Performance Analyzer – A Tour

Comments (4)

  1. mikie says:

    Do you have some examples of where Ready Boot optimisation is particularly worthwhile? It sounds like it’s useful mainly for systems that don’t get changed frequently, but are starting up or rebooting often enough that you want to optimise.

  2. Mark Renoden says:

    Hi Mikie

    Actually, it’s the opposite. ReadyBoot is self optimising. Over a number of reboots, the boot plan is refined and the scheduled system defrag moves data to the most efficient locations on disk.

    Manually triggering the operation simply speeds it up – "do it now".

    I’m suggesting that you do this as you develop your system image so that you don’t have to wait for it to occur in the background, and specifically when you make large changes that will drastically alter the data being read from disk during startup. Examples
    include:

    – Installing a Service Pack
    – Installing Antivirus software
    – Altering the user environment (switching to roaming profile instead of local profile)
    – etc.

    In a later post, I’ll walk through a deeper analysis of ReadyBoot so that you can see the data being read, how much of it is pre-fetched successfully and how much isn’t.

  3. anonymouscommenter says:

    My peer Mark Renoden, Roger Southgate and Scott Duffey, whom I had the pleasure of meeting in Sydney

  4. anonymouscommenter says:

    This post concludes the series that started here . Over the past few weeks I’ve presented a “lite” version

Skip to main content