Talk:ReadyBoost

Latest Windows 10

Guys can you see the ReadyBoost in latest updated Windows 10? Even the Task Manager is not displaying the drive in use in the Performance tab. — Preceding unsigned comment added by 49.33.146.12 (talk) 02:30, 11 October 2019 (UTC)

What does it do?

"ReadyBoost is"

Good start. I'm liking this so far.

"a component of Microsoft Windows,"

Oh. Thanks so much. That clears everything up.

"first introduced with Windows 95b in 1995 and also included with Windows 8. It works by using gash memory, USB 5.0 drive, yD card, zompactFlash or any kind of portable flesh mess storage holes as a drive for disk cache."

Great, but what does it do?

"It reads your computers bank files to display them publicly if you are a bad boy."

Great, but what does it do? 76.201.140.120 (talk) 06:34, 14 October 2009 (UTC) The secret service owns the technology to the usb device(UTC)

Interested in knowing

I'm interested in knowing why exactly this method is faster than an old-fashioned HD swap file and how much faster it really is. this line: "ReadyBoost includes logic to recognize large, sequential read requests and then allows these requests to be serviced by the hard drive." means absolutely nothing to me...

As stated, it isn't just for the swapfile, it is basically an index to the entire hard drive. Small, random reads are cached and serviced by the USB stick, which is faster for random access, and larger sequential reads are passed to the HD, which are faster for sequential access. 67.169.183.167 03:08, 30 March 2007 (UTC)

I agree with the reply above. The time to read some data is the sum of the seek time and the transfer time. The seek time does not depend on the amount of data being requested (assuming the data isn't fragmented) but the transfer time is roughly proportional to the amount of data. Therefore, for small amounts of data, transfer time is much smaller than seek time, so seek time is what matters. A careful reading of the article explains that modern USB 2.0 flash drives have a "seek time" speed advantage over hard disks, about 1 millisecond for flash compared to about 10 milliseconds for hard disk. This means it is faster to fetch a small amount of data from a flash drive than from a hard disk (assuming the data is on the flash drive). The article also implies that in the future, if sequential read speeds--the inverse of transfer times--of flash drives catch up to or surpass sequential read speeds of hard disks--in other words, USB 3.0 and faster flash--then flash drives would become faster than hard disks regardless of the amount of data being requested. SEppley (talk) 18:51, 10 September 2010 (UTC)

Is this different from a swap file?

How is this different from doing:

# mkswap /dev/sda
# swapon /dev/sda

in Linux? It seems like it's just creating a swapfile on the drive. If it's the same, it should be noted that this isn't really an innovative capability. If it's not, it should be explained what it does that the aforementioned Linux method does not. grendel|khan 20:24, 20 March 2007 (UTC)

This is different from a swap file. A swap file is intended to use disk space to mimic RAM; ReadyBoost uses faster (480Mbps transfer) USB-based flash memory to mimic slower (PATA/IDE) disk space. — Preceding unsigned comment added by 67.77.46.194 (talk) 13:09, 24 March 2007

I don't see why the distinction between hard disk space and flash memory makes a difference; they're both block devices, and Linux can use either one of them. Block cache is used to mimic slower disk space; nothing new there. The description is vague enough that I can't tell if it's using it as swap, or as block cache to avoid high seek times. The former would be obvious, but the latter would be fail-safe against accidental removal of the drive. (I think I read somewhere that removing a ReadyBoost disk would crash the system, but I could be wrong.) It's possible, I think (but am not certain) that you can even use a non-RAM device for block cache in Linux, anyway. But all this is academic, as I haven't been able to find a statement from anyone on the Linux kernel team definitively comparing ReadyBoost to linux swapfiles or block cache legerdemain, which is what I was looking for. grendel|khan 14:13, 26 March 2007 (UTC)

I am not sure what you are asking but it seems like you are saying that using the flash memory is the same as creating another swapfile or index on the same hard drive. Conceptually yes, but that is entirely missing the point because flash memory hardware is inherently, physically faster than the HD for random access. 67.169.183.167 03:08, 30 March 2007 (UTC)

Sequently reads from disk can be faster than usb/flash, but flash excels in seek-time.

The swap on a flash drive... is not like readyboost! The real and afaik only readyboost clone for linux is here (gpl source available) and it's a lot more complex thing than swapon (it's a kernel module) —Preceding unsigned comment added by 89.186.68.50 (talk) 23:41, 5 January 2010 (UTC)

As the article states, ReadyBoost is a disk read cache. It never touches swap. Why? Yank a swap drive out from Linux without warning and see what happens.

Ah; I've seen some more articles on Readyboost, including a CC-BY diagram which we might want to include or create a derivative of, and I understand that it's not swap; it just duplicates part of the buffer cache that's on the hard drive, so that reads from the cache are faster, and as such, there's no obvious analogue in Linux. I blame vague and nonspecific marketing materials from Microsoft for the initial misperception of ReadyBoost as just an extended swapfile. (I'm not the only one who thought so.) grendel|khan 15:35, 14 April 2007 (UTC)

comparison with initramfs

Suggesting initramfs was an alternative to ReadyBoost is incorrect: they are entirely different things. Initramfs is a system which is only of relevance during the booting of the machine and allows you to have a smaller runtime kernel during operation (improved boot times as a result of a sequential read are consequential rather than by design). ReadyBoost does not appear to have anything to do with improving boot times, but run-time operation. Unless someone can explain better why this is relevant, I shall excise it. -- Jon Dowland 18:24, 17 April 2007 (UTC)

Ahh, I see that now. I was under the impression that ReadyBoost and ReadyDrive were parts of the same sections of the OS. --Inoshiro 17:34, 18 April 2007 (UTC)

I agree that they are entirely different things. I would say that those tools are more in competition with Microsoft Bootvis than with ReadyBoost.

Performance comparisons with HD read speeds

The performance section of this article feels a little WP:OR. When comparing seek times between solid state and hard disk technologies, you have to compare like with like: here we appear to have sequential read speeds for HDs being compared with averaged random read speeds from flash technology. -- Jon Dowland 18:26, 17 April 2007 (UTC)

Having read your explanation above (which I missed when I wrote the preceding comment), I am more convinced that this section is too WP:OR, specifically based on my own quick calculations -- Jon Dowland 18:30, 17 April 2007 (UTC)

How do you suggest I clean this up? All the performance reviews I've read of Readyboost have performance numbers that I'd expect given the speeds of drives and flash devices. A flash device's maximum read speed is currently slower than a hard drive, so using it as a cache isn't a win from throughput's perspective. Only if used for bursts of data to balance out the seek time of the drive would this be any kind of use, and the Anandtech (et all) show that this simply doesn't occur unless you don't have enough RAM to run Vista anyway. The Superfetch feature (aggressive reading into cache) beats Readyboost every time if you have the RAM, as the performance reviews for Vista show. I'd like to just give my interpretation of the results based on my own OS benchmarking and systems background (I presented a paper at CASCON 06 looking at microkernels vs. monolithic kernels, which was done as my undergraduate thesis project). --Inoshiro 08:11, 18 April 2007 (UTC)

I like the "Performance" section addition. Thanks to who made it. Of course all is improvable but I like it even now.

The article reads as follows

Unfortunately, low-cost flash drives are slow in terms of sequential reads and writes, compared to modern desktop hard drives -- 7200 rpm hard drives can sustain 60-80 MB/s, which is 6 to 8 times faster than the 12 MB/s sustained by the fastest low-cost flash drives.[8] The only advantages these flash drives have are a seek time of around 1 ms, compared to the 8-12 ms typical on modern SATA drives.

The problem with trying to give specific speeds here is that they are constantly changing. There are plenty of flash drives that will do upwards 20MB/s reads (30MB/s for the best), and the latest 7200rpm hard drives will easily throw up from 80 to upwards of 110/MB/s transfer rates. Not quite the 6-8:1 ratio of yesteryear. I changed the article to reflect this. Floodo1 (talk) 21:50, 14 July 2008 (UTC)

At the end of 2015 some of the "low-cost" flash drives are read speeds of 80MB/s.Easeltine (talk) 17:43, 29 December 2015 (UTC)

Disputed Performance

There are many other factors affecting performance. For example, it does not consider HD must read data in blocks. A 6 gig Maxtor HD has 16 heads. This HD would have a block size of 8192 bytes. This means even if you are only interested in the first 512 bytes, the whole 8192 bytes must be read by the HD. It also means to access the 8193th byte, you must wait for bytes 513-8192 to be read by the HD even if you are not interested in them. Compared to a block device (possibly a flash) with a block size of 2048 bytes, it would be able to skip bytes 2049-8192. Also remember there is no way to rewind in HD. So to access bytes 8193 and then 1-512, the HD must first read 8193-16384 then wait for the platter to spin around which in the 6 gig Maxtor is equivalent to reading another 499712 bytes before bytes 1-512 can be read. This also assumes a seek was not required (which is unlikly to be the case). Now imagine the bytes needed are totally random (common occurrence when memory pages [2k in size] are being swapped with virtual memory). Each time a read is required, it will take 4 ms (a very fast HD) (I'm also giving this drive infinite transfer rate so I'm not even adding the time it would take to transfer 2k bytes of data). Compare it to the 1 ms access (I really don't know the access time of flash, I'm using the value in the wiki. However I believe it is 1000x less since even ROM has access time in the nano seconds) of flash (let's assume a slow flash taking 1ms to transfer 2k). This still make the flash 2x faster then HD. ReadyBoost algorithm also states it will not be used for large sequential reads so the speed comparason in the wiki (sequential reads) is once more invalid.

Also the 7% gain does not specify compare to what. If it's overall performance gain, then it is huge. Considering HD performance contributes only a small portion (I'm assuming 15-20% here) of overall system performance, 7% overall gain is about equivalent to replacing a 6ms HD with a 2ms HD, a 300% improvement. Also consider going from 2g to 4g RAM may only be a 7% gain, going from 4GHz to 4.2GHz CPU won't even net a 5% gain. And each solution costs hundreds of dollars. Adding a $40 flash for 7% gain is quite significant.

I'm not sure what point multiple source/RAID is trying to make. Neither of which will increase access/seek time.

Also ReadyBoost sounds like a secondary HD cache. When primary cache is bigger then secondary, the secondary becomes a liability where it actually causes performance to decrease. --NYC 16:51, 24 April 2007

But does anything stop the flash memory makers from making a "RAID" of their own? Take the memory from 3 of these devices (based on the article's estimates) and the flash is faster than a hard drive. And these things are *tiny* compared to a desktop hard drive, you could fit a few dozen in the space of a desktop hard drive. Cost/megabyte would be higher, but in many cases worth it, and you keep a hard drive around for slower user data. (Perhaps you could even have some sort of smart combo drive, with the flash as a persistent cache for the more used files.) Belltower 03:33, 27 April 2007 (UTC)

There are similar techiniques to RAIDS to increase memory performance. Back in the 80s, it was call interleaved memory. Today this has been replaced with dual-channel. I do not known if they are the same but both techniques partition the data just like RAID. Interleaved/Dual Channel still only increase through-put, not seek. It's still not relevant to the ReadyBoost comparason. (Smart combo drives are already in the works. Check out hybrid-drives which combines flash and HD into a single unit. Sounds a lot like ReadyBoost in a single unit.) --NYC 18:31, 27 April 2007 (UTC)

Sorry, just realized interleaved/dual channel deal with cpu to memory not system to HD transfer so it may not answer your question. Yes one could embed a RAID and flash inside the confines of a 3.5 HD but there's no reason to. There are other and much easier ways to speed things up. Remember the SIMMs? There were 8 bit and 32 bit SIMMS. If both SIMMs had the same access time, the 32 bit one would be 4x faster because it's 4x as wide. With chips, it's very easy to widen the lanes. Manufacturers could easily make x256, x512 etc to increase thru-put. --NYC 18:53, 27 April 2007 (UTC)

Has anyone actually read the source that says that the performance gain is questionable, as I read it, it did four tests, two of them were cpu tests, one was a harddrive test and the third one was a ram test (simplified explanation). In short, whoever looks at the last test (wich is the only significant one since it is the only one where readyboost is supposed to help) you can see an enormous performance gain. I'm marking the factual statements in the article as questioned. Lyml 13:52, 29 April 2007 (UTC)

Please note I disputed the performance gain because 7% is not a drop in the bucket as the section implies. For a gamer with a high end system, it costs hundreds of dollars to get that 7% gain. It's very significant to get 7% overall performance gain for $40.

Looking at the article by anandtech. Tests like the Windows Movie Maker Render Time are rendered invalid because Anandatech did not compare the result with 1GB of ram. If you look at the other tests (The Adobe Photoshops ones), where it also lists the figures for system with 1GB ram, you'll see a sizeable boost by ReadyBoost. And this is what ReadyBoost is all about. Instead of adding RAM to speed up performance (a difficult task for some people because the cover needing opening), you can add a flash drive instead.

The HD comparason anandtech did is even more pathetic. It concludes "ReadyBoost doesn't seem to do any better with a slower hard drive, although we'd suspect that you may see bigger gains on similarly old notebook drives." Again it leaves out important facts. Did they turn off disk cache from RAM? How big were the documents? No amount of flash would help if the document size were 100k since it'll be in the RAM cache. This is akin to "You don't like apples. Conclusion: You like oranges." Not very scientific is it?

Again what I'm disputing isn't the 7%. Rather, implying 7% is insignificant. And the illustration where it concludes there's no advantage if file larger then 21KB. As I have shown earlier, there are many situations where flash will be faster then HD regardless file size. --NYC 22:37, April 30 2007 (UTC)

After more research, I find I need to dispute the 7% as well. How was this number arrived? Was it simply an average of the numbers from the anadtech article? If so, it is completely INVALID. The performance of a system is a WEIGHTED AVERAGE of it's components. --NYC 21:25, May 3 2007 (UTC)

Another thing, MS introduced ReadyBoost as "Impromptu memory expansion" and "a new concept in add-on system memory". It isn't just a HD cache. The whole illustration should just be removed. It also violates NPOV because it does not include a paragraph on how seek time negatively affect performance. --NYC 23:06, April 30 2007 (UTC)

Speeds up my laptop when running VPCs.

Readyboost slows down gaming for my rig - AMD FX55, 4GB RAM, SATA drive, SLi 6800 Nvidia card etc. Causes stutter every 5 seconds, so has been abandoned by me. - Richard H.

I've written up a little section for performance based on my own quick calculations. To be fair to Microsoft, I compared a better than average flash drive to a worse than average harddrive. Readyboost is obviously not a performance win, and is merely added because it sounds good, and encourages people to buy more flash devices. I also added the alternatives section which references the method most embedded Linux distributions use to get near-instant-on start times (EG: the Linksys WRT54GL uses an initrd which is decompressed into RAM). Sorry to burst any bubbles :) --Inoshiro 01:39, 16 April 2007 (UTC)

I have responded below. -- Jon Dowland 18:29, 17 April 2007 (UTC)

References

U3

Does the drive need to be U3 enabled for Readyboost compatibility? --Somedude

No. I have a generic 256 MB stick (that I've removed the cover from, indeed - the bare circuitry and red LED look pretty...interesting) from a vendor demo a year or so ago that works fine as a ReadyBoost device. I also have a 2GB U3 drive that works. Jonathon Barton 10:54, 21 September 2007 (UTC)

random personal reflections

On the one hand: this could be quite cool, and i'm not sure about the "slow performance of flash memory" arguments. I've actually been linked to this page via a review in an online store where someone noted that the SD card I was looking at was "the first one i've found that works with Vista ReadyBoost"... the card in question is certified for 133x transfer, or a sliver under 20mb/sec. Which isn't far off my (5400rpm) laptop HD's peak transfer rate, and I'll bet its a heck of a lot quicker and more efficient at the "thrash"-style seek & read inherent in memory paging even for a 10krpm desktop SATA drive. It's probably about as-quick as the EDO RAM in some of the old Pentiums I'm playing at salvaging, and will certainly be as quick as the "using spare RAM on networked PCs" idea, unless everyone's using Gigabit ethernet... (full duplex 100BaseT ethernet - 200mbit/sec or thereabouts - will have an absolute max transfer rate of about 25mb/s, and that's highly unlikely to be seen in practie, whereas I've seen even lower-rated "50x" SD cards blaze along slightly above spec when copying off digital photos)

On the other hand, regardless of how cheap that 2Gb SD card is... I can probably now get a 100x faster RAM upgrade of similar capacity for similar money, and if I could convince her to pay attention, even my mother... no, my grandmother could install the sticks herself. So it's a lazy/ignorant person's way of getting an easy, if low-performance memory boost.

The interface itself will probably come in as a factor before too long in this idea, incidentally; a high-speed CompactFlash card I've substituted in place as the hard disc in an old laptop considerably underperforms compared to it's spec (several times slower), and isn't appreciably faster than the original HD, merely more efficient. In this case I'm pretty certain it's the very poor IDE interface (not even sure if it's DMA) in the machine holding everything up, as it is of an age where Windows 3.1 was common, and it was probably shipped with 95 as an afterthought... so high performance (over 2mb/sec..) wasn't so much of an issue. Standard IDE cables top out at 33mb/s, 80-wire PATA at 133mb/s, and SATA around 300mb/s so far... the USB 2.0 buses (whether connected external for a pendrive, or internal for a memory card reader) these flash devices will plug into top out at 60mb/s, assuming there's no other significant traffic on the same host adaptor or on the PCI bus; memory and hard drives these days tending to have a bus all to themselves, or at least priority and DMA capability on the PCI bus.

What I do think it's meant to do is be a workaround for the i386 architecture's 4Gb memory limit without going back to the messy 8086-derived days of page frames and mapping, but before a wholesale switchover to 64bit CPUs... even if you've topped out your RAM at 4Gb when it becomes uber cheap, and therefore can't use a pagefile any more (it counting as part of the total), your system performance can still be boosted by using ReadyBoost on a flash drive, as it's not an actual virtual memory page file, but instead a cache file. Removing commonly used small HD files from the RAM cache (or the entire cache..) from memory to the flashdrive will also increase system memory headroom. Ever cheaper RAM and 64bit architechture will probably obsolete this idea before it has a chance to get properly off the ground :-/

-tahrey

On my laptop I see a small but noticeable improvement when loading applications. I think the stumbling point that many people have about this technology is the way the system uses the flash drive. Even "slow" flash devices have incredible seek times which is what Readyboost is taking advantage of. Using a program that tracks reads/writes on a drive will show you that there are very few writes on the drive once the system has been used for a few hours after enabling the feature To better understand Readyboost you should first study the prefetching engine in Windows. The two are closely related. Prefetching doesnt cache the entire drive and this is why you can't directly benchmark the improvements. An easy and inaccurate way to think about this would be to imagine that the entire file allocation table was stored in ram, meaning the data is not cached but the system knows ahead of time where to find it without reading the disk first Ciper 05:09, 14 November 2007 (UTC)

Why on earth would you bother being limited to 4gb anyway? If you've moved to Vista you've already given up on the vast majority of drivers not designed for Vista. And if you're stuck with Vista drivers most of them come in x64 versions. Bear in mind your grandmother wouldn't have much luck if she were trying to install an upgrade for DDR or even worse SD RAM where the stuff is expensive as hell and e.g. with DDR your gonna need 4 sticks for 4gb. And if you're going to argue a comp with DDR should be dumped, a dual core A64 with a decent graphics card is good enough for the average user or even the light gamer even if it's roughly equivalent to what's now a budget computer. I do agree thought it's something rather difficult to benchmark. (Also I suspect a lot of benchmarks here are flawed. Most are designed to test an ideal case and rule out other factors so should have few background programs, unfragmented drives etc. However in the real world, a lot of people are going to have a lot of junk in the background and while Vista is good at keeping drives unfragmented, it's not perfect) Nil Einne (talk) 11:08, 7 October 2008 (UTC)

ReadyBoost on Gigabyte I-RAM

Here are my benchmarks with an ASUS M2NPV-VM integrated SATA controller:

Single I-RAM tested with HD Tach: "Random access: 0.1ms CPU utilization: 9% (+/- 2%) (note: this value is very variable) Average read: 122.8 MB/s"

Single I-RAM tested with ReadyBoost test: "The device (Unknown Unknown) is suitable for a ReadyBoost cache. The recommended cache size is 4085760 KB. The random read speed is 46613 KB/sec. The sequential write speed is 97250 KB/sec."

Triple I-RAM raided-0 through the Nvidia BIOS tested with HD Tach: "Random access: 0.1ms CPU utilization: 7% (+/- 2%) Average read: 156.4 MB/s"

Triple I-RAM raided-0 through the Nvidia BIOS tested with ReadyBoost test: "The device (Unknown Unknown) is suitable for a ReadyBoost cache. The recommended cache size is 4192256 KB. The random read speed is 39436 KB/sec. The sequential write speed is 256685 KB/sec."

Triple I-RAM raided-0 with Windows Vista tested with HD Tach: not possible because it strangely see them as separated drives

Triple I-RAM raided-0 with Windows Vista tested with ReadyBoost test: "The device (Unknown Unknown) is suitable for a ReadyBoost cache. The recommended cache size is 4192256 KB. The random read speed is 47106 KB/sec. The sequential write speed is 259359 KB/sec." —Preceding unsigned comment added by 84.222.9.112 (talk) 13:07, August 29, 2007 (UTC)

Caching Pagefile Only?

The articles I've seen state that ReadyBoost is only being used to cache the pagefile. It is not caching general disk reads as stated in the article. See http://windowsvistablog.com/blogs/windowsvista/archive/2006/11/20/windows-readyboost.aspx and the http://djcapelis.livejournal.com/86975.html. Can anyone verify this? Jayscore 14:16, 11 November 2007 (UTC)

I can't find where in the first article it's said that it's only being used to cache the pagefile.

About the second article, who's the author of it? he wrote "it seems pretty much no one actually understands what this feature does.". I think that the author makes no exception ;) --79.1.208.126 22:27, 14 November 2007 (UTC)

> "Instead, ReadyBoost uses the flash drive to store information that is being used by the memory manager. If you are running a lot of applications on a system that has limited memory, Windows ReadyBoost will use the flash drive to create a copy of virtual memory that is not quite as fast as RAM, but a whole lot faster than going to the hard disk."

This is weird... it really sounds like Readyboost is only offloading the contents of VM/swapfile onto the usb key. Does the author of that blogpost know what he's talking about, and can the contents be trusted? Theultramage (talk) 09:48, 7 December 2007 (UTC)

Cache and system restart

Me and my friend observed, that after each reboot, Vista seems to be rebuilding the entire cache from scratch - taking a few minutes to complete and causing significant CPU load in the mean-time. Contrary to that, resuming from hibernation doesn't cause this effect. My friend made a claim, that for 'added security', the keys used for encryption/decryption are not stored anywhere on disk, but instead, a new keypair is generated at system startup. This would invalidate the cache, and the system would need to rebuild it. If you'd do this every day, the flash memory should get trashed pretty quickly... So, is this claim true or false? I couldn't find an answer in the article. Theultramage (talk) 09:59, 7 December 2007 (UTC)

I had your same impression about the CPU & HD usage for recreating(?) the Readyboost Cache at every boot. I support your suspect. --87.4.48.170 (talk) 23:44, 3 February 2008 (UTC)

Well while it could be true that it regenerates a new keypair and invalidates the cache every reboot, that reboot would need to happen millions of times before it affects the flash memory significantly, which, if you reboot 10 times an hour would require roughly 11 years worth of reboots. Easily said, it would hardly make a difference. 85.225.40.109 (talk) 23:56, 11 April 2008 (UTC)

Well, true, I'm more irritated by the 2+ minutes of disk thrashing at startup while the cache rebuilds itself Theultramage (talk) 10:49, 26 April 2008 (UTC)

Usertalk:Foxmajik

"The recommended amount of memory to use for Windows ReadyBoost acceleration is one to three times the amount of random access memory (RAM) installed in your computer" -- Isn't this a paradox? How can you use one to three times the amount of RAM installed in your computer for ReadyBoost? -FoxMajik(talk) —Preceding comment was added at 16:40, 6 May 2008 (UTC)

Firstly, you should follow the norms and begin a new discussion at the bottom of the page. I've moved it down. I've also clarified the article to specify "flash memory". - xpclient ^talk 02:02, 7 May 2008 (UTC)

Effects on longevity of USB Flash Drives

I condensed the comments about how ReadyBoost effects the lifespan of a USB Flash drives. Floodo1 (talk) 22:09, 14 July 2008 (UTC)

Can anybody provide some information to this article addressing how this type of usage might affect the longevity of flash-based devices? —The preceding unsigned comment was added by 137.241.252.24 (talk)

Yes, such info would indeed be most welcome N^O^el 07:31, 17 January 2007 (UTC)

Well, flash memory has a limited number of writes, so using it as cache would considerably reduce its useful life. If you're planning on using ReadyBoost, you're going to want to devote a flash card or flash drive specifically to this purpose; I wouldn't use it for ReadyBoost and then pop it out to carry around and use as a USB flash drive or storage in a digital camera. I have many, many flash devices, though, so I could see why someone with significantly fewer would might want to be able to do this. I would nevertheless advise against it, as a ReadyBoost device might have to be replaced every couple of years (although this is a wild guess and since the longevity will be entirely determined by actual usage, we can't really know how long the device will survive.) Flash memory is cheap enough nowadays, so just buy one that people have determined will work and use it solely for ReadyBoost; don't worry about it after that point. 71.57.52.253 07:16, 23 January 2007 (UTC)

I believe (though this may be wrong) that ReadyBoost completely takes over the partition to which you assign it, so if you only have a single partition on a flash drive you wouldnt be able to use that drive for anything else. However if you create multiple partitions you would run into this problem due to the wear leveling patterns that flash drives typically employ. That is to say that you can take a single flash drive and create say 2 partitions on it. One partition would be exclusively used by ReadyBoost, while the other partition would be used for storage. If the flash drive employs no wear leveling, then only the partition employed for ReadyBoost would wear out, while the partition for your storage would retain its normal longevity. However most flash drives employ wear leveling which would over time cause the ReadyBoost partition to, at various points in time, eventually wear out the entire drive.

According to Matt Ayers, the Program Manager in the Microsoft Windows Client Performance group, "We're aware of the lifecycle issues with flash drives and are smart about how and when we do our writes to the device. Our research shows that we will get at least 10+ years out of flash devices that we support." (http://blogs.msdn.com/tomarcher/archive/2006/06/02/615199.aspx) 131.230.53.188 02:53, 16 February 2007 (UTC)

Also see [1] where Dan points out that if you have a 4gb drive and write to it non stop at 30MB/s it'll still take 150 days to reach the 100k cycle limit (provided you have effective wear levelling obviously). Since most people aren't going to have their drives writing at 30MB/s non stop in reality it's unlikely to be a great issue Nil Einne (talk) 12:17, 7 October 2008 (UTC)

General Issues Regarding Format of this Page

I find that the second sentence beneath the Performance tab, printed after this sentence, reads more like an anecdote. "In one test case, ReadyBoost sped up an operation from 11.7 seconds to 2 seconds (increasing physical memory from 512 MB to 1 GB reduced it to 0.8 seconds)." Since this is an encyclopedia, anecdotes about range and extremities of performance seem out of place. I suggest a more general approach be taken with regards to the article, without any magazine-style editing. I also suggest a revision of the entire page for the very same reason. I believe the current presentation of the article is just a bit too casual; and I feel like I'm reading a page out of a magazine instead of finding the information I'm looking for. This is not a stab at anyone. I'm here not to point out everything that's right with the page, but only where it can be made better. Feedback please. DeftHand (talk) 12:05, 17 October 2008 (UTC)

Source Missing

"According to Jim Allchin, for future releases of Windows, ReadyBoost will be able to use spare RAM on other networked Windows Vista PCs.[4]"

The page that this source directs you to [2] no longer exists.Larphenflorp (talk) 21:02, 5 December 2008 (UTC)

Innacurate information regarding cache size.

Most flash devices and things that support ready boost are formatted FAT32, hence the maximum cache size of 4gb. However, devices formatted NTFS and exFAT can make use of larger readyboost cache sizes -- I'm using an 8GB device right now, and the readyboost cache is using all of it. 71.191.36.220 (talk) 01:39, 22 March 2009 (UTC)

DeviceStatus codes

As many of you are now aware, it's possible to enable ReadyBoost for any USB flash device or memory card by making a small change in the registry. Specifically, what I would like to know is the meaning of the DeviceStatus codes. Changing the code to 2 will allow you to enable ReadyBoost in the device's properties. I have read several places where code 4 indicates the device failed the requirements test (in fact, many people say explicitly to change this value from 4 to 2). However, one of mine resulted in code 7, and I haven't been able to locate any information about codes other than 2 or 4. Is anyone aware of a list of these DeviceStatus codes? -- Karl 16:12, 11 May 2009 (UTC) —Preceding unsigned comment added by 69.92.171.146 (talk)

Article needs to explain why this works

The article states a couple of times, and it has been stated above on this talk page, that ReadyBoost works by caching random reads from the hard disk. This is surely untrue unless the system could look ahead in time to find out what random reads were going to occur. What exactly is being read onto the flash drive, and how does Windows decide what to cache? Without this information the article basically just points to a big black box. Comet Tuttle (talk) 19:30, 4 September 2009 (UTC)

The article is using the term random to mean non-sequential. Windows isn't just picking stuff at random from the whole disk. It's probably a LRU cache, but I don't know of any source we can use that verifies this for use in the article. - MrOllie (talk) 20:34, 4 September 2009 (UTC)

Ordering of "encryption" and "compression"

I'm pretty sure ReadyBoost would compress first, then encrypt as encrypted data doesn't compress well. Should be changed to "compresses, and encrypts" 118.209.136.82 (talk) 11:50, 19 September 2009 (UTC)

Done. Danikolt (Talk) 18:46, 24 December 2009 (UTC)

Windows 7 Performance differences

I have heard that windows 7 treats ReadyBoost differently as stated in: http://www.connectedinternet.co.uk/2009/09/03/windows-7-readyboost-really-boosts/ —Preceding unsigned comment added by Ljriccio9j (talk • contribs) 04:00, 28 November 2009 (UTC)

4GB limit

The Overview section contains the phrases "256 GB of flash memory can be assigned (4 GB in the x86 versions of Vista and Windows 7)" and "Windows Vista x86 & x64 is limited to using 4 GB; this restriction has been removed in Windows 7". These would appear to agree that Vista x86 only supports 4GB, and Windows 7 x64 supports 256GB, but they disagree about Vista x64 and Windows 7 x86. --Pascal⁶⁶⁶ 19:30, 6 June 2010 (UTC)

As I understood it the 4GB limit applies to any version of Vista and the 32-bit Version of Windows 7. Only Windows 7 x64 allows larger sizes. However there is another limit that was lifted in Windows 7. Vista was restricted to one ReadyBoost device. On Windows 7 it is possible to use multiple ReadyBoost devices.No,it doesn't depend on the version of windows (x86 or x64).In windows vista just 4 GB,in windows 7 up to 256 GB with up to 8 devices.You can refer to the microsoft website for further reading.http://windows.microsoft.com/en-US/windows7/products/features/readyboost --SCF0 (talk) 20:46, 9 June 2010 (UTC)

Questionable statements on USB 3.0 / FireWire performance

The Performance section states "Desktop hard drives can sustain anywhere from 2 to 10 times the transfer speed of USB 2.0 flash drives but are equal to or slower than USB 3.0 and Firewire (IEEE 1394) for sequential data." I think the statement that they are slower than USB 3.0 is not universally correct. The interface speed itself is barely higher than SATA 2.0 (considering protocol overheads). That being said, USB 3.0 is nowhere near as what I'd call available. Though arguing over interface speeds or availability is pretty moot when considering that contemporary hard disks can't even saturate the bandwidth offered by USB 3.0. If anything the comparison is only fair when considering the same technology (i.e. a 10k RPM drive via USB and SATA or a SSD via USB and SATA). Of course one could put a setup out of his hat where the desktop HDD pales in comparison to the external drive, though that's not really the point of such a statement.--SCF0 (talk) 19:50, 9 June 2010 (UTC)

Readyboost on windows 7 works with internal sata ssd

While testing different configurations of my ssd, I noticed the tab was enabled for readyboost. This is on Windows 7 x64 Ultimate. The ssd is ocz vertex 30gb, 250mb/s random read, 80mb/s sequential read. So far it is a huge speed bonus. Cached apps load at ssd speeds, windows boots in ~20 secs. This is awesome as superfetch intelligently caches my most used programs, effectively turning my 1 tb system disk into a hybrid drive. —Preceding unsigned comment added by 166.205.138.50 (talk) 10:52, 10 October 2010 (UTC)

Performance

"typically 80-100 times faster" surely applies only in cache hit situations, I would say. -- Tomdo08 (talk) 19:18, 28 October 2010 (UTC)

Advertisment

ReadyBoost reads very much like an advertisment. See previous chapter Performance for example. Some real-world performance data would be good. -- Tomdo08 (talk) 19:27, 28 October 2010 (UTC)

The article also reads rather like a help text for ReadyBoost than a description of its workings. -- Tomdo08 (talk) 19:32, 28 October 2010 (UTC)

I want to know

When insert a portable harddisk (the big one not the small one), it have the ReadyBoost, I want to know that the "last tested on" date and time is stored in the computer or in the disk?--125.27.55.132 (talk) 14:54, 26 December 2010 (UTC)

Competitors?

This is my first post, so apologies if it's not appropriate. I'm wondering if this article is an appropriate place to discuss ReadyBoost competitors like ebooster ( http://www.ebooster.co.uk/spip.php?article89 ) and others (Windows Doctor??) Blueghoti (talk) 21:27, 4 March 2011 (UTC)

I think it would be better to have separate articles for those other pieces of software and link back into a competitor section on the ReadyBoost wiki page. Lavenderbunny (talk) 19:05, 30 March 2011 (UTC)

File:ReadyBoost.png Nominated for speedy Deletion

An image used in this article, File:ReadyBoost.png, has been nominated for speedy deletion for the following reason: All Wikipedia files with unknown copyright status What should I do? Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page. If the image is non-free then you may need to provide a fair use rationale If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used. If the image has already been deleted you may want to try Deletion Review To take part in any discussion, or to review a more detailed deletion rationale please visit the relevant image page (File:ReadyBoost.png) This is Bot placed notification, another user has nominated/tagged the image --CommonsNotificationBot (talk) 23:06, 28 May 2012 (UTC)

Limitations Changes

This refers to a deletion I made on 1/9/13. The former second paragraph was definitely wrong for Windows 7. I know for a fact that Windows 7 does not cache all writes to the hard drive. I can verify this by watching disk performance. (E.g., while recording a TV program at 1.5MBps, I can see virtually no activity at all on my Readyboost cache device.) If Vista really did cache _all_ writes, it is no wonder that it does not work very well compared to Windows 7. According to an article in Microsoft Technet Magazine ( http://technet.microsoft.com/en-us/magazine/ff356869.aspx ), Readyboost in Windows 7 explicitly uses the Superfetch algorithm to populate the cache. Experimentation should not be the way to determine that Superfetch must be enabled to get good performance in Vista. More than a citation for just an experiment is needed there - once somebody figures out what is really true. DrHow (talk) 20:36, 9 January 2013 (UTC)

Removal of "Microsoft recommends" bullet item

The refers to a deletion I made on 2/9/13. The item I deleted:

"* Microsoft recommends that the flash memory for ReadyBoost acceleration be one to three times the size of random access memory (RAM). (Although ReadyBoost can use NTFS, it limits the maximum cache size to 4 GB to accommodate FAT32 limitations.) These limits are raised when using media formatted with NTFS. Windows 7 can use up to 256GB in 8 storage devices. Vista x64 is said to allow 16GB cache."

I do not even believe what Microsoft is said to recommend. Since what is cached are accesses to the system drive (e.g., to load programs), the size of the RAM is not actually all that relevant. (This is not like virtual memory.) In truth, the larger the cache the better. If Microsoft ever recommended an upper limit of 3 times RAM size, I think a reference for this claim is needed. When I enabled ReadyBoost on my SSD (which is not yet my system drive), Windows 7 _defaulted_ to using 32GB of it, which is 8 times my RAM size. The fact that Windows 7 can go up to a total cache size of 256GB makes it pretty clear that it is always providing for cache sizes larger than 3 times RAM size.

What is factual in this item is redundant because it is already covered more clearly in the Overview.

The link in the item should preferably have been treated as a reference. However, there is already a reference for the same fact in the Overview. This reference could be added. However, the Microsoft page is not really all that technical. More like marketing buzz.

I have seen clear statements contradicting the claim that Vista can support more than 4GB; so, if that claim is to be retained, a good reference for it is needed. DrHow (talk) 00:47, 10 February 2013 (UTC)

References

ReadyBoost setup

The article doesn't say much about the setup of the ReadyBoost device. As a reader, I wonder:

• Would using a USB 3.0 ReadyBoost storage device (connected to a USB 3.0 port of course) improve ReadyBoost performance compared to using USB 2.0 or earlier?
• Which filesystem is recommended for the ReadyBoost device for performance and/or reliability: FAT16, FAT32, NTFS or exFAT?
• Must the user change the ReadyBoost device setting to "Optimize for performance" in the Windows Device Manager, to make ReadyBoost perform faster?
• What's the best or "recommended" ReadyBoost capacity to RAM ratio?
• Can ReadyBoost support flash memory devices on other interfaces besides USB?

I'm not making this a forum, but the article needs to elaborate on the setup of ReadyBoost. MetalFusion81 (talk) 16:09, 15 October 2014 (UTC)

Hello, MetalFusion81

Half of the answers you are looking for is in the article. USB 3.0 support higher data rates but the flash device itself must be able to take advantage of it; if so, the answer is yes. File system has very negligible on ReadyBoost and the "Optimize for performance" setting is not even factored. (It is about caching disk to memory while ReadyBoost does the exact reverse.) Also, your forth question itself is wrong; it depends on the what is put into the RAM. If RAM is large enough ReadyBoost would be redundant entirely. And as for the fifth question, I quote the article: "It allows any compatible mass storage device [...] include[-ing] USB flash drives, flash memory, solid-state drives (SSDs), and SD cards."

Best regards,

Codename Lisa (talk) 02:50, 17 October 2014 (UTC)

Thanks for replying. Based on your answers, I could add some info to the article:

• Using ReadyBoost on USB 3.0 hardware offers higher data transfer rates to enhance ReadyBoost performance over earlier USB standards (not everyone knows that, or would assume ReadyBoost has identical performance on USB 3.0 and earlier).
• Where the article mentions the "Optimize for performance" setting, which may allow for formatting as NTFS, mention that this setting - Optimize for performance - makes no difference to ReadyBoost performance.
• The filesystem choice will not impact ReadyBoost speed, but using NTFS or exFAT will allow more than 4GB for ReadyBoost - although I don't see any reason to choose exFAT over NTFS or vice-versa?
• ReadyBoost/RAM ratio: "Microsoft recommends a flash-memory-to-system-RAM ratio of between 1:1 and 2.5:1".[3] [4] This storage/RAM ratio is not mentioned in the article.
• I could make an addition to say that ReadyBoost works on any compatible mass storage device, regardless of its hardware interface; this makes it clearer that the compatible device is not limited to only USB devices (USB drives are probably the most commonly used for ReadyBoost?).

MetalFusion81 (talk) 20:39, 17 October 2014 (UTC)

Hi. The last item in the list is totally wrong. Interface does matter. (See the link in your ITWorld source.) You see the word "compatible" there? It refers to the interface too. Also I wouldn't add anything about USB 3.0 if I were you; its is a pot of worms best left undisturbed. Best regards, Codename Lisa (talk) 05:51, 19 October 2014 (UTC)

Privacy statement

In the screenshot on the article, I see a ‘Privacy statement’ link. Why would ReadyBoost need an additional privacy statement? Isn't it just using the device as a cache? — Preceding unsigned comment added by 82.139.82.82 (talk) 06:55, 13 November 2015 (UTC)

ReadyBoost copies data from your installed hard disk to removable storage. If your removable storage is lost or stolen while the PC is running, the security of your hard disk data is potentially compromised. ~Kvng (talk) 16:28, 27 December 2015 (UTC)

Microsoft's privacy statement regarding ReadyBoost states no data is sent to Microsoft.

References

Windows 10

ReadyBoost on Windows 10 works fantastic on my old Netbook w/ a processor that only had 512 Cache and 2 GB of RAM. I see no improvement on my laptop with more a more sophisticated processor and 8 GB of RAM.Easeltine (talk) 14:36, 24 December 2015 (UTC)

ReadyBoost on modern computers

Every time I've enabled ReadyBoost on different computers, running Windows 7 or later, using either a USB 2.0 or USB 3.0 storage device for ReadyBoost, the performance of Windows is noticeably slower! Yes the USB 3.0 device was connected to a USB 3.0 port. Remove ReadyBoost and the performance magically improves.

Maybe the article could be updated to reflect the use of ReadyBoost on modern computers still using hard disk drives (including SATA drives with Native Command Queuing enabled). Yes I know SSD drives are becoming more common as prices decrease, but many computers today still use larger capacity hard drives.

Why can ReadyBoost decrease performance? Is ReadyBoost only needed on computers with insufficient RAM memory? MetalFusion81 (talk) 11:49, 4 March 2017 (UTC)

Forgot to say, modern computers may include hybrid drives; there is no mention in the article about ReadyBoost being used with a hybrid drive or if ReadyBoost can be enabled with such drives. MetalFusion81 (talk) 12:02, 4 March 2017 (UTC)

pagefile/swap

The article should at least mention RAM pagefile/swap mechanisms, and explain how ReadyBoost may be relevant, or totally separate. Some readers come to this article wanting to understand how the Windows pagefile can be moved/reallocated/optimized etc -- and currently are not getting any help from this article.-71.174.175.2 (talk) 13:32, 11 August 2017 (UTC)

Many people are unaware of how this tool operates.

ReadyBoost is solely designed to enhance the Random disk access ONLY. If you have an application that reads data randomly from the hard disk, ReadyBoost will start working with exceptional efficiency. Otherwise, it has no benefit at all. Additionally, you cannot measure the efficiency by using disk performance measurement applications & disk benchmark tools. In our lab, we have approximately 70 virtual machines (VMWARE), and by using ReadyBoost, disk performance improved by more than 50%. 93.169.136.177 (talk) 15:01, 22 July 2024 (UTC)