AnandTech Article Channel |
| Haswell GT3e Pictured, Coming to Desktops (R-SKU) & Notebooks Posted: 10 Apr 2013 04:21 PM PDT One of the worst kept secrets is Haswell will have four different GPU configurations: GT1, GT2, GT3 and GT3e. As with Sandy Bridge and Ivy Bridge, higher numbers mean more execution units, with GT3 topping out at 40 EUs. The lowercase e denotes an embedded DRAM part, with some amount of DRAM on the Haswell package itself (not on-die). In an awesome scoop, the folks at VR-Zone managed to snag a photo of what looks like a quad-core Haswell die with GT3e graphics. The small package to the left should be the Lynx Point chipset (8-series), while the dual-die package on the right is Haswell + DRAM. The big square die should be Haswell itself with its 40 EU GPU, while the smaller die is the DRAM itself. Intel hasn't officially acknowledged the existence of GT3e, but it did demonstrate performance of the part at CES earlier this year - targeting somewhere around the speed of NVIDIA's GeForce GT 650M. The DRAM size, operating frequency and bus width are all unknown at this point. I've heard the DRAM itself should be relatively small, looking at the chip shot we get some indication but there's no confirmation of the specific type of memory we're looking at here (which obviously impacts die area). Haswell GT3e will be available both in notebooks and desktops, however neither will come in socketed form (BGA-only). The desktop parts will carry an R suffix. This will be the beginning of Intel's socketed/soldered strategy on the desktop, which as of now is set to work sort of like tick tock - with the first chips on any new process being sold exclusively in BGA packages. Haswell will have socketed desktop SKUs, Broadwell won't, Skylake will, etc... GT3e use in notebooks will be limited to larger designs it seems. Don't expect to find this level of graphics performance in a low wattage Ultrabook part, but it will likely surface in bigger notebooks - perhaps those driving ultra high resolution panels. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Hardware Accelerated BitLocker Encryption: Microsoft Windows 8 eDrive Investigated with Crucial M500 Posted: 10 Apr 2013 10:28 AM PDT Most modern SSDs come with some form of hardware encryption. On these drives with hardware encryption, it’s usually permanently turned on - all data written to the NAND is typically stored in encrypted form. This stems from the fact that all writes to NAND had to be scrambled to begin with (writing long repeated strings of data to NAND can cause problems for data retention). The earliest implementations weren’t sophisticated enough to be considered real encryption, but these days it’s not uncommon to see hardware AES-128/256 support. The bad news has been that relying on OS driven filesystem encryption always meant the use of software encryption on top of your drive’s native encryption. This was particularly a problem on SandForce based drives, where full disk encryption basically ruined any of the performance advantages of the controller’s native compression/de-dupe (you can’t further reduce encrypted data). Other drives suffered (just not as much) due to the added overhead from having to leverage the host CPU to encrypt all data before writing it to disk. There’s also the fact that if you encrypt your entire drive (free space included), the drive ends up looking like a completely full drive - which has performance implications of its own. This was the world that existed with BitLocker under Windows 7 and FileVault under OS X. With Windows 8, the story is a bit different. I hadn’t heard of Microsoft’s eDrive standard for Windows 8 until I started working on the Crucial M500 review. It turns out that if you have a storage device (e.g. SSD, eMMC, etc...) that meets the right encryption standards, Windows 8’s BitLocker will leverage the device’s hardware encryption engine, bypassing the software based encryption altogether. The result should be better performance and lower power consumption. The M500 is the first drive that I’m aware of to support Microsoft’s eDrive standard. Because of its TCG Opal 2.0 and IEEE-1667 compliance, the M500 is eDrive compatible. There are some platform requirements to get eDrive working as well. You’ll obviously need a system that will support BitLocker (although hardware TPM isn’t necessary, you can still go the USB key route). It’s important to note that you have to enable UEFI boot and make sure you have a UEFI enabled Windows 8 install in order for this to work. Your platform will specifically need to support UEFI 2.3.1 (Class II no CSM/Class III). Often times UEFI boot support on motherboards can be tricky, particularly on earlier firmware revisions, so be sure you’re updated (this was the problem I ran into with my test hardware). I've had varied luck with getting DIY desktop PC hardware to behave appropriately with UEFI and BitLocker enabled, so your mileage may vary. The experience on a TPM enabled notebook should be far cleaner from what I've heard. With all of your ducks in a row, all you need to do is enable BitLocker at this point. If everything is eDrive compliant you won’t be asked whether or you want to encrypt all or part of the drive, after you go through the initial setup BitLocker will just be enabled. There’s no extra encryption stage (since the data is already encrypted on your SSD). If you’ve done something wrong, or some part of your system isn’t eDrive compliant, you’ll get a progress indicator and a somewhat lengthy software encryption process. For example, with 107GB in use my test 240GB M500 was fully encrypted with BitLocker enabled after a couple of seconds. Just a pause, then boom, BitLocker was enabled. My 256GB Samsung SSD 840 Pro on the other hand took about 21 minutes to encrypt the very same data using software encryption. The gallery below shows all of the steps I went through to enable BitLocker/eDrive support on my Intel DX79SI motherboard with Crucial’s M500.
The ability to quickly enable/disable BitLocker is a nice perk, but it’s only part of the story. There’s basically no change in performance with BitLocker enabled on the M500 since the encryption is all done on the drive (and was always being done there to begin with).
The sad reality is, Samsung’s 256GB 840 Pro with software encryption enabled ends up being faster than the M500 running as an eDrive, but in theory if the drives were equal performers you’d see a clear advantage to the eDrive compliant hardware. PCMark 7 isn’t the most stressful test and we’re really only measuring peak performance here however. Given that the 840 Pro should look like a completely full drive with its free space encrypted, I ran a short 4KB random write test to see whether or not that was the case:
Now this is much more interesting. On a mostly empty drive, the 840 Pro behaves like it’s full of data and thus shows lower peak 4KB random write performance. The M500 on the other hand behaves like it’s empty. As neither one of these drives has the best behavior after extended usage in a full state, the long term performance benefits are tremendous. There should be power savings associated with running as an eDrive, although since my testbed is a desktop PC they aren’t all that visible. The irony here is that none of the modern (UEFI 2.3.1 hit in mid 2011) PC notebook hardware I have on hand will support a 2.5" SSD. As someone who regularly uses full disk encryption, I can’t tell you how excited I am at the thought of eDrive compliant SSDs. There’s absolutely no reason this shouldn’t be how all OS level encryption works. Kudos to Microsoft for making this happen and to Crucial for supporting it. I’m hoping we’ll see more eDrive compliant SSDs in the future. For now, anyone who is required to run with BitLocker enabled should seriously consider Crucial’s M500. On the Mac side, I do hope Apple will follow Microsoft’s lead here and build similar support in to OS X for FileVault. The power and performance savings are worth it, especially when you consider that SandForce based SSDs are now in Apple’s official parts bin. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| You are subscribed to email updates from AnandTech To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google Inc., 20 West Kinzie, Chicago IL USA 60610 | |
No comments:
Post a Comment