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 -
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.
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
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.
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.