Intel's Haswell NUC: D54250WYK UCFF PC Review
by Ganesh T S on January 3, 2014 4:25 PM ESTThe NUC as an HTPC
The form factor and network streaming power consumption profile of the Intel D54250WYK NUC makes it a very attractive option for HTPCs. We have already covered Haswell as a HTPC platform in great detail before. So, we will just take a look at a couple of interesting aspects which may vary from one build to another.
Refresh Rate Handling:
One of the most important fixes in Haswell for HTPC users was increased display refresh rate accuracy. We have already seen 23.976 Hz working perfectly in our custom Haswell HTPC build. The gallery below presents the various refresh rates that we tested out on the Intel D54250WYK NUC.
As expected, the refresh rate accuracy is excellent across all tested points. One of the pleasantly surprising aspect was that the drivers allowed forcing of refresh rates not reported by the display through EDID. This must have come in a recent update, because, when I was evaluating our first Haswell HTPC build, the i7-4765T based PC refused to drive 50 Hz on the Sony KDL46EX720. However, the NUC was able to do it successfully after deselecting 'Hide modes not supported by this monitor'.
Decoding and Rendering Benchmarks:
Detailed decoder / renderer benchmarks for Haswell were presented in our initial review. For the NUC, we are going to concentrate on XBMC's native decoding / rendering (used by the average HTPC user) and the combination of QuickSync with EVR-CP and madVR.
We used MPC-HC v1.7.1 for evaluation. LAV Filters 0.59.1.26 come pre-integrated as the default choice with that version. madVR 0.86.11 was configured with the following options: no decoding, deinterlacing automatically activated when needed with deactivation when in doubt (decided by only looking at pixels in the frame center), chroma upscaling set to bicubic with a sharpness of 75, image upscaling and downscaling done by GPU video logic using DXVA2 calls, rendering in full screen exclusive mode with playback delayed until fill up of the render queue, a separate device for presentation, CPU and GPU queue sizes of 128 and 24, 16 frames presented in advance, smooth motion features disabled and the default quality-performance tradeoffs of 16b pixel shader results and subtitle quality optimization for performance.
A number of experiments were done with different madVR settings and this was the one with which we were able to play all our test streams without frame drops. It must be noted that the streams benchmarked are meant to stress the system. The usual media file played back is more of the 1080p24 variety which goes comparatively easy on the resources compared to the 60 fps streams used for the tables below.
| QuickSync Decoder + EVR-CP | |||
| Stream | GPU Usage % | CPU Usage % | Power Consumption |
| 480i60 MPEG-2 | 23.02 | 7.55 | 11.27 W |
| 576i50 H.264 | 20.80 | 6.68 | 10.97 W |
| 720p60 H.264 | 33.04 | 16.53 | 13.70 W |
| 1080i60 H.264 | 38.72 | 16.44 | 14.66 W |
| 1080i60 MPEG-2 | 37.29 | 12.82 | 13.95 W |
| 1080i60 VC-1 | 35.53 | 14.31 | 14.61 W |
| 1080p60 H.264 | 41.98 | 19.88 | 16.05 W |
| QuickSync Decoder + madVR | |||
| Stream | GPU Usage % | CPU Usage % | Power Consumption |
| 480i60 MPEG-2 | 44.66 | 9.72 | 15.59 W |
| 576i50 H.264 | 49.02 | 10.98 | 16.01 W |
| 720p60 H.264 | 58.57 | 24.98 | 19.27 W |
| 1080i60 H.264 | 56.97 | 35.28 | 23.60 W |
| 1080i60 MPEG-2 | 54.76 | 33.13 | 23.17 W |
| 1080i60 VC-1 | 56.49 | 34.00 | 23.19 W |
| 1080p60 H.264 | 60.21 | 27.92 | 27.01 W |
| XBMC 12.3 | |||
| Stream | GPU Usage % | CPU Usage % | Power Consumption |
| 480i60 MPEG-2* | 23.92 | 7.32 | 11.20 W |
| 576i50 H.264 | 11.23 | 4.44 | 9.23 W |
| 720p60 H.264 | 28.80 | 8.79 | 11.99 W |
| 1080i60 H.264 | 16.71 | 7.42 | 10.78 W |
| 1080i60 MPEG-2 | 16.52 | 6.04 | 10.22 W |
| 1080i60 VC-1** | 5.23 | 5.34 | 8.71 W |
| 1080p60 H.264 | 33.62 | 8.16 | 13.05 W |
The only disappointing aspects above are related to the native decoder / renderer used by XBMC. Interlaced VC-1 decoding is broken when hardware accelerated decoding is enabled. Deinterlacing, particularly for the 480i60 stream, was not properly performed with any combination of settings. On the other hand, QuickSync decoding works smoothly (as expected) for all the test streams when used with any renderer.
Facebook
Twitter
RSS
107 Comments
View All Comments
chrnochime - Sunday, January 5, 2014 - link
Burned haha. Go ask this question on any english forum worth its salt and realize how wrong you are LOLandrusoid - Thursday, January 9, 2014 - link
Not a double negative. Read a book, preferably one concerning grammar and english usage. "So you actually agreeing with ddriver." Something's missing. By the way, "dis" is not negation. (This is not a double negative statement, as well.)theangryintern - Friday, January 10, 2014 - link
That sounds like a confession to me. In fact the double negative has led to proof positive. I'm afraid you gave yourself away.ddriver - Saturday, January 4, 2014 - link
You can be sorry and disagree all you want but this will not change the facts.That particular atom chip is a POC, slower than even mid-range contemporary phones, with terrible GPU (cripples browser rendering performance) and running a bloated OS. I have very smooth experience with both "desktop" websites (I hate crippled mobile versions) and with PDFs sporting high resolution images (here the reader implementation plays a tremendous role) on my phone (note 3) - that type of content is literally FLYING. I haven't been printing from the phone yet, but I am pretty sure it will not take minutes to print a 20 page document.
And don't think for a moment that I am used to sluggish performance and therefore have lower standards and expectations. My desktop config: i7 3770k 32gb samsung 830 SSD - while 2 years old, by no means a sloth.
BehindEnemyLines - Sunday, January 5, 2014 - link
It makes me wonder why Chrome OS laptops are moving from ARM to Intel x86 (Haswell) if it's "slower than even mid-range contemporary phones"? I mean, Chrome OS started with ARM, and it's pretty lightweight.Gigaplex - Sunday, January 5, 2014 - link
An old Atom is slow, not Haswell.lhl - Friday, January 17, 2014 - link
I have both the Samsung Series 3 (Exynos 5) Chromebook and the new Haswell-based C720. Performance difference/day-to-day usability is night and day, the C720 blows aways the ARM Chromebook. While I'd imagine TDP to be slightly higher, the C720 actually has much longer battery life (8h vs 5h) while only being 3-4 ounces heavier. The C720 also has better build-quality, screen, keyboard, and trackpad...JohanAnandtech - Sunday, January 5, 2014 - link
I guess I will have to benchmark it to prove it. You are downplaying the N2800, but it was close enough to a 1.4 GHz Quad Cortex A9 with a 2 MB L2 (Calxeda ECX-1000). That is very similar to the current midrange Phone. In fact, given how bandwidth bottlenecked most ARM CPUs are, the 4 MB L2 would probably give that chip an edge over the current midrange.virtual void - Sunday, January 5, 2014 - link
There is something about Intels CPU-design vs ARM that does not show in benchmarks like Geekbench and similar. Even the old Z2460 (single core "old" Atom) platform still feels quite snappy when running Android, the "feel" of this SoC is way better than what one would believe when looking purely at benchmarks.My guess is that Intels CPU-cache design, especially L2, still is a couple of notch above what any ARM CPU vendor current got.
shodanshok - Sunday, January 5, 2014 - link
I absolutely agree. In the past I tried to show that as benchmark results show, a single Atom Core is quite comparable to anything between one and two A9 cores. However, many poster simply choose to ignore this fact, accusing me to be totally wrong...