Talk:ReadyBoost

From Wikipedia, the free encyclopedia

 This article is part of WikiProject Microsoft Windows, a WikiProject devoted to maintaining and improving the informative value and quality of Wikipedia's many Microsoft Windows articles.
B This article has been rated as B-Class on the assessment scale.
Mid This article has been rated as mid-importance on WikiProject Microsoft Windows's importance scale.

I'm interested in knowing why exactly this method is faster than an old fasioned 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)

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)

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.

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)

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)

Contents

[edit] 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.

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)

[edit] 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.

[edit] 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.

[edit] 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" [1] 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.


[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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". Any other reason why you find this article is written like an advertisement? Please let the contributors know which parts sound like an ad so they may change it. Please don't simply tag and run away. - xpclient talk 02:02, 7 May 2008 (UTC)