Thread: Anandtech News

It is nearly impossible to begin to review the HTC One without some context, and I’ll begin our review of the HTC One (formerly the device known as codename M7) much the same way I did my impressions piece simply by stating that HTC is in an interesting position as a result of last year’s product cycle. If there’s one thing Anand has really driven home for me in my time writing for AnandTech, it’s that in the fast-paced mobile industry, a silicon vendor or OEM really only has to miss one product cycle in a very bad way to get into a very difficult position. The reality of things is that for HTC with this last product cycle there were products with solid industrial design and specs for the most part, but not the right wins with mobile operators in the United States, and not the right marketing message abroad. It’s easy to armchair the previous product cycle now that we have a year of perspective, but that’s the reality of things. HTC now needs a winner more than ever.
For 2013 HTC is starting out a bit differently. Rather than announce the entire lineup of phones, it’s beginning with the interestingly-named HTC One. It’s just the HTC One — no S or X or V or any other monikers at all. It’s clear that the HTC One is the unadulterated representation of HTC’s vision for what the flagship of its smartphone lineup should be. HTC is different from other OEMs in that it only makes smartphones, and as a result the flagship clearly defines the rest of the product portfolio below it. With the One it looks as though HTC is making that kind of statement by literally letting it define the entire One brand.
Enough about the position and the strategy for HTC, these are mostly things that are interesting to enthusiasts and industry, but not really relevant to consumers or the review of a singular product. Let’s talk about the HTC One.


More...

Iomega / LenovoEMC launched an updated version of the LifeLine OS for their NAS devices last week. The new release (v 4.0) will be compatible with the existing StorCenter ix and px series devices in the market. Some of the interesting features / updated capabilities being introducied in the new version include snapshots, SSD caching, VM host capability (a first in the SMB NAS market) and NFS v4.
The SSD caching (cache pools) feature automatically caches frequently accessed files on a pool of SSDs. RAID protection is also available for these cache pools. The new OS also brings Twonky Media Server v7 integrated for SOHO / home users. The most exciting feature is undoubtedly the IVX integrated virtualization technology which allows the px12 rackmount arrays to run multiple virtual machines (Linux or Windows) with their own private virtualized hardware. This feature is particularly helpful in situations where a lightweight Linux web server or a machine running non-intensive Windows services need to run in conjunction with a multi-bay high performance NAS.

One of the main issues with LenovoEMC's LifeLine OS is the fact that many of the features are available only in the px series and not the ix ones. This time around, LenovoEMC has helpfully provided us with a feature matrix that we have reproduced above.
The update will be made available later this week for existing StorCenter owners and pre-installed NAS devices will launch in May. Hit the source link for more information on the new features in the newest version of LifeLine OS.



More...

Last year we hinted that another Thunderbolt revision would happen this year, with a speed bump in 2014. It turns out that's exactly what's being announced at NAB this week. Intel took the opportunity to unveil its first 2013 Thunderbolt controllers as well as tease next year's Thunderbolt spec update. As a refresher, Cactus Ridge was the codename of the Thunderbolt controllers that accompanied Ivy Bridge systems. Haswell gets a new set of controllers: Redwood Ridge.
Intel is announcing two this week: the DSL4510 and DSL4410. These two are replacements for Intel's current DSL3510 and DSL3310, with 4/2 and 2/1 (channels/ports) respectively. There are no performance changes other than official support for DisplayPort 1.2 (and thus 4K displays). If you connect either of these parts to a Thunderbolt display you still only get DP 1.1a support. There's still a PCIe gen 2 x4 interface on the other end of these controllers.
The Redwood Ridge parts should be a little cheaper as they integrate a 1V voltage regulator that used to be external. The integration also reduces board area by a bit. Power consumption is also lower at idle compared to Cactus Ridge, and disconnected power consumption is significantly lower (1mW vs. 7mW for Cactus Ridge). Redwood Ridge includes the appropriate hooks for Haswell's upcoming aggressive platform power management reductions. Ultimately this is the real focus behind Redwood Ridge. With Haswell, all components on the platform need to be more power efficient - Intel's own silicon included.
Next year Intel will introduce Falcon Ridge, the first real performance upgrade to Thunderbolt. Intel is only mentioning an increase in performance to 20Gbps, which I can only assume refers to signaling speed per Thunderbolt lane. If that's correct we'd be looking at a doubling in peak theoretical bandwidth over Thunderbolt, perhaps finally making this interface useful for external GPUs. No word on a release timeframe for Falcon Ridge, but my guess is that we'll see it debut around Broadwell (14nm Haswell shrink). Given that Haswell is a late Q2/Q3 launch at best, I'd say end of 2014 is likely for Falcon Ridge.
Dropping power, BOM cost and increase performance in the future are all great, but Thunderbolt adoption on the PC remains embarassing at best. There's a lot of finger pointing between Intel and Microsoft on this, but none of it matters to the end user. Apple continues to be the only platform player that seems to get Thunderbolt and take it seriously. If Intel wants Redwood or Falcon Ridge to matter, it needs to make sure that we actually see real adoption of Thunderbolt in the PC space - with backwards compatibility guaranteed between those devices that have been shipping on the market for a couple of years now.



More...

Intel has released an updated OpenCL driver for their 3rd Generation Core (Ivy Bridge) and 4th Generation Core (which we can safely call as Haswell) products that brings OpenCL 1.2 support on both the CPU and the GPU, moving a step up from OpenCL 1.1 in previous releases. The driver also implements better integration with both Direct3D and OpenGL. The driver is for Windows 7 and 8 only. Intel has also released an updated SDK along with the driver. The full release notes for the SDK release can be found here. Intel also supports OpenCL 1.2 on Xeon Phi.
Also of note, Intel has also recently updated their VTune Amplifier 2013 tool to add support for collecting GPU performance metrics in OpenCL applications running on Intel GPUs. Now it is possible to collect metrics such as utilization of the Execution Unit (EU) array and usage of on-chip local memory and cache of Intel HD graphics from within VTune. This will enable programmers to better understand the performance characteristics of their code on Intel GPUs, and thus will allow them to optimize their code better. According to an Intel forum post, for full GPU functionality VTune does require that the BIOS in the developer's machine support an option to collect performance metrics on the Intel GPU. This may be problematic for some developers. For example, I have a notebook with HD 4000 but was not able to enable some metrics because my notebook's BIOS does not have this option.

AMD has provided similar tools (such as CodeXL), as well as OpenCL 1.2 drivers for their GPUs for quite a while. Nvidia provides mature profiling tools for CUDA applications but their OpenCL tooling has been lackluster at best and Nvidia drivers remain at OpenCL 1.1. Overall it is good to see Intel continuosly upgrading their driver and tool support for GPU computing APIs.



More...

This is probably the most excited I've been about any SSD launch in quite a while. At CES this year, Crucial announced its M500 SSD - the world's first to use Micron's new 128Gbit MLC NAND die. Courtesy of the cost savings and density increase associated with this new 128Gbit NAND, the M500 would be available in a 960GB capacity, priced at $599. That works out to be around $0.62 per GB for a truly gigantic drive by today's standards. It's exciting. For the past five years I've been learning to live off of less storage that I thought I needed, but the M500 had the potential to spoil me once again.


More...

Yesterday Intel announced its updated Redwood Ridge Thunderbolt controllers (adding 4K/DP1.2 support, lower power operation and slightly lower BOM cost) as well as next year's Falcon Ridge family of Thunderbolt controllers. I assumed that Falcon Ridge would ship alongside Broadwell in late 2014 but I just got word that the new Thunderbolt controllers will begin production by the end of this year and ramp volume through 2014. I don't have more specific dates than that, but it's still good news.
All Intel is saying about Falcon Ridge is the spec includes a speed bump to 20Gbps per lane up from the current controllers with 10Gbps per lane. Intel's own presentation refers to a single channel/two lane Falcon Ridge controller, delivering no additional bandwidth above existing TB implementations (although there may be practical advantages since you can't easily aggregate all TB channels today). I would assume that we'd see even higher bandwidth implementations but Intel isn't talking about any of that today.



More...

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.
Gallery: Enabling eDrive Support on Windows 8 with Crucial 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).

PCMark 7 - Raw System Storage Score
	Unencrypted	BitLocker Enabled	Perf Impact
Crucial M500 240GB (eDrive)	4644	4586	-1.2%
Samsung SSD 840 Pro 256GB	6195	5336	-13.9%

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:

Peak Performance - 4KB Random Write (8GB LBA Space, QD32)
	Unencrypted	BitLocker Enabled	Perf Impact
Crucial M500 240GB (eDrive)	63334.8 IOPS	62865.8 IOPS	-0.7%
Samsung SSD 840 Pro 256GB	88911.3 IOPS	63097.53 IOPS	-29.0%

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.



More...

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



More...

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.



More...