Intel Next Unit of Storage (DE3815TYKHE NUC kit)

  • Hey, so although I posted a thread some time ago asking about this, I finished building it and have been tinkering with it for the past few months.


    I thought I would share some pictures, and my experience thus far.


    Cost:
    This box itself I picked up on sale for $90 CAD. I had confirmed working ram (4GB Crucial) sitting in my drawer at home, and the CAT6 cable and Seagate Firecuda 2.5" 1TB SSHD were about $110 CAD together. For 30 dollars I purchased an MLC USB drive with good reviews and decent advertised transfer speed (Transcend JetFlash 780) for the boot drive. In addition I picked up a WD Blue 3.5" 5400 RPM 1TB drive and Nexstar TX powered 3.5" usb 3.0 external HD enclosure for ~ $80 CAD. I also purchased a CyberPower 350VA UPS ($60 CAD) so that I wouldn't need to worry about power outages (they're rare where I live anyway). In all the cost was around $360 CAD. Technology isn't really cheap in Canada, sadly, but I feel I've gotten good value for money and learned a lot and had fun along the way.
    --------------------
    Build:
    It's pretty difficult to think of a task easier than building these thin client/nettop PCs, as they are usually tool-free (or close to it) installations. Not much to say here. As this is actually intended for commercial use (signage etc.) it was probably a little less user-friendly than the current generation of NUC marketed at home use, but a bit of sweat and fiddling with the drive cage and 20 minutes were all it took to get to the point of installing OMV.
    --------------------
    Performance:
    I had posted a thread in the General config forum about a high load issue on this box. I have yet to really pin down the source of this issue beyond something do to with the cpu/mem usage output displayed on a few pages in the OMV webui. Changing a few settings around (limit nginx to 1 worker process as the box is single core, install sysfsutils and raise scaling_freq_min to roughly 933mhz instead of 533mhz) which seems to have ameliorated the problem somewhat, but it does appear every now and again. I have Pi-hole DNSBL/DHCP server installed on the same box (no docker, virtualbox, anything) and this runs perfectly fine and generates virtually no load, so I'm kind of thinking there's something funny going on with the webui but just haven't33 had time to investigate further.


    Otherwise performance is great, even when the box was loaded by the webui to values over 2, SMB/CIFS and NFS shares work great. Streaming x264 media is a flawless even when this strange load condition appears.


    Drive temperature in the box has never risen above 42*C (and it was about 30*C ambient temp that day), and cpufreq-info reports even when I'm streaming videos to multiple devices that the processor is running at 933-1GHz (the full clock speed is 1.46GHz). With ClamAV on the RAM usage has not risen above 18% of 4GB.


    I think this would be a great single bay NAS unit. If you could buy a few of these at a time it would be fairly simple to just hand them out to your friends or family and provide yourself a little location independent data redundancy (in return for read-only access to your media library?) ;) I had seen them for similar prices on ebay, in my mind I view it as being only a slightly larger investment than an RPi/3 (with case charger and an EVO+ you're looking at close to $90 CAD anyway)
    --------------------
    Caveats:
    There are only 2 usb 2.0 ports and only 1 single usb 3.0 port. The boxes do not come with wifi chip but they do have an available m.2 port. Who cares though, it's a nas.


    There is a strange issue with the omv web-ui wherein sometimes the system information pages displaying cpu/mem usage will generate runaway load conditions exceeding values of 2.0


    The unit is fanless, if you live in a very hot place it might not be suitable for your use


    The technology is now a little dated (2014) and so power consumption could probably be more efficient, in addition the processor isn't going to wow anybody. Subtract three cores from an RPi/3, add gigabit lan and a sata 3.0 gbps port and you've got the NUC Kit DE3815TYKHE.
    --------------------




    If you happen to see one of these locally or online for a good deal, and want something to play with, I would recommend it. Not too shabby! The build quality is nice, the unit feels pretty solid. Has been running for a little over a month now and very stable.


    Images are hosted on imgur, click for a larger version.


    Cheers and let me know if you have any questions.




    Thanks for all the hard work devs! :thumbup: Awesome piece of software you have here. Hope to help out somehow.


    Cheers,
    Drinks2go

  • Writing this thread, I had forgotten there was a 4GB eMMC included on the SoC. So today I have decided to switch from the usb-boot method to install on the eMMC and see how that goes.


    It is only 3.36 GB available with 1.29 GB used post installation, therefore I will need to make a configuration to rotate logfiles out of /var/ and into my data disk. Hopefully this will allow me to use the eMMC until it dies with this installation, provided there aren't any problems. I think it is a pretty slow eMMC, 30MB/s read lmao. The initial apt-get update took forever.


    I will update this thread in a few months time with my findings.

    • Official Post

    Hopefully this will allow me to use the eMMC until it dies with this installation, provided there aren't any problems.

    Since "until it dies" can be defined by a finite number of write cycles, (if you haven't done so already) don't forget to install the openmediavault-flashmemory 3.4.4 plugin and follow the instructions on the plugin page to finish the install. This plugin greatly reduces boot drive writes which makes flash devices last much longer.


    Frankly, you might consider using USB thumb drives to boot because of the ease of cloning them. After all the configuring, etc., if one fails or an upgrade goes south, it's easy to pop in the backup. If rebuilding from scratch can be easily avoided, why not? (Just a thought.)

  • I had considered that but I feel that reliable usb drives are not so easy to come by these days.


    I have noticed the load is much lower using the eMMC/flash memory as opposed to a good USB/flash memory. Still spikes somewhat, I suspect now this is just because the processor is so underpowered.


    But even rsyncing a local backup, streaming a video and uploading media via nfs simultaneously doesn't cause any instability. That group of tasks generated a 2.8 load at one point this morning.

    • Official Post

    I had considered that but I feel that reliable usb drives are not so easy to come by these days.


    I have noticed the load is much lower using the eMMC/flash memory as opposed to a good USB/flash memory. Still spikes somewhat, I suspect now this is just because the processor is so underpowered.


    But even rsyncing a local backup, streaming a video and uploading media via nfs simultaneously doesn't cause any instability. That group of tasks generated a 2.8 load at one point this morning.

    I've had good luck, so far, using SanDisk USB drives. However, without the FlashMemory plugin, they won't last long. USB drives can't withstand anywhere near the number of write cycles of an SSD. (The main consideration is If they have wear leveling. SanDisk has wear leveling, where generics may not.) In any case, it's the write cycle weakness that causes me to maintain a gross quantity of them.


    For my primary i3 server, I have 3 each USB drives. I configure things up the way I want them and "read" the resultant image onto a PC (this file becomes a 4th copy of the boot drive). I then write that image to the remaining 2 USB drives. The original goes in a drawer and the remaining 2 drives get the updates (that can go south) and the daily wear and tear. So far, there have been no failures or any issues that might be attributed to them.


    I also have an R-PI that uses SD-Cards. (Again, I have 3 each and a similar method for masters. 2 each get all the wear and tear.) In this case I foolishly bought "generic" cards. In 2 or 3 years, I've had them fail on 3 or 4 occasions. Once, the failure occurred after an upgrade. The other 2 or 3 failures happened with no explainable reason. On the other hand, with spares on hand, losing a boot drive is no big deal. I just pop in a spare. But what remains a mystery is what is actually going wrong. I've tested every SD-card "failure" (if that's the correct way to characterize it) using the h2testw utility. Without an exception, no errors were found so I reformat them and use them again. They only way I might see a difference is to replace all SD-cards, with a higher quality item, but since I have a good system to work around the perceived problem, I haven't bothered.
    ________________________________________


    If all you're doing is hosting some local network shares, a bit of Rsync'ing, and streaming an occasional video on a LAN with a couple users, even with an under powered processor, I think you did the right thing by installing OMV. With the WEB GUI (no desktop), OMV is brutally efficient. I'm using an r2 B+ Raspberry PI (with 1 whole GB of ram) with a 4TB ext drive, as a data backup server, and it's doing a fine job.

  • Funny, I think I spent more on my RPi microsds than I did on my usb drives.. I would like to get a good SLC USB and test that, using the opportunity to test a backup of my omv setup once it's complete .


    (working on a bit better Pi-hole integration than @raulfg3 provided in his guide and maybe Squid3 also if the box can handle it).


    For that reason losing a boot drive is a bit more of an issue for me :P

  • I was thinking again about your comments today @flmaxey and was thinking it might be a better/more interesting use of the emmc to put an image of OMV 3.X (to reinstall incase of borking) and possibly gparted Live or something. Similar to the recovery partition on many laptops/desktops. What do you think? I could do this with two usbs connected to the Nuc, one with the gparted/OMV images and one with maybe another gparted or something to just wipe the eMMC and then write the images to it.


    Then I could test by installing to the transcend usb I was using as a boot drive earlier in the week. I could probably even just transfer the images to the SATA drive in the NUC and write them to the emmc by mounting /dev/sd(SATA DISK ID) .... so only one usb would be needed.

    • Official Post

    I was thinking again about your comments today @flmaxey and was thinking it might be a better/more interesting use of the emmc to put an image of OMV 3.X (to reinstall incase of borking) and possibly gparted Live or something. Similar to the recovery partition on many laptops/desktops. What do you think? I could do this with two usbs connected to the Nuc, one with the gparted/OMV images and one with maybe another gparted or something to just wipe the eMMC and then write the images to it.


    Then I could test by installing to the transcend usb I was using as a boot drive earlier in the week. I could probably even just transfer the images to the SATA drive in the NUC and write them to the emmc by mounting /dev/sd(SATA DISK ID) .... so only one usb would be needed.

    It's a thought but I'm not sure how that would work in practical terms. I'm guessing that the onboard eMMC has boot priority by default (and would register as dev/sda). I imagine you could set the boot priority in bios to be anything you like, where a USB drive or another drive type could become the boot drive. That would mean that you'd have to make a change in bios to boot to a rescue setup but, in a rescue situation, that wouldn't be a big deal. (It would mean hooking up a monitor and KB.) If you could figure out a way to make an exact copy of OMV from a USB drive, to the eMMC, you'd have an on-board backup that could be accessed with a bios boot order change. (Again, a monitor and KB.)


    Really, I like that idea of using the eMMC like this because you wouldn't be running a butt load of write cycles to it, on a regular basis. (It's permanently installed - you can't replace it.) While I don't have a device with an eMMC mounted, as I understand them, they're more common on embedded devices where continuous write cycles are not a factor. In a role as the boot drive for OMV, an eMMC is no better than a decent quality USB drive for enduring write cycles. So, "yes"; it makes sense to consider a useful role for it where it's not taking day to day wear.

  • I had considered that but I feel that reliable usb drives are not so easy to come by these days.


    I have noticed the load is much lower using the eMMC/flash memory as opposed to a good USB/flash memory. Still spikes somewhat, I suspect now this is just because the processor is so underpowered.


    But even rsyncing a local backup, streaming a video and uploading media via nfs simultaneously doesn't cause any instability. That group of tasks generated a 2.8 load at one point this morning.

    If i remember correctly the "war" of firewire vs USB, one of the benefits for FW was that it has more power in te controller, where the USB needed more CPU power. And the later was cheaper but took more CPU power and increased the need of upgrading (very neat feature if you are a CPU vendor).
    Could the CPU spikes be that using USB uses CPU power more than using the eMMC/flash memory...?


    Would you still recommend it as a simple one drive NAS OMV ? Any performance text?


    How did it go, was it easy to swap to the eMMC storage for the OS (OMV)?

    Newbie on OMV... not so new on hardware/software in general, started on the "14.400 bps"-era. Windows-guy, eger to learn more linux.
    - pfSense and OMV is my next thing for small office usage.

    Edited 2 times, last by rudis ().

  • Hey sorry for missing your post here.


    The performance is still very solid. Given I am a bachelor living in a small apartment and typically only have one device streaming media from the OMV box, it's hard to say whether or not this means much for 90% of OMV use-cases. I will try to stream from a few different devices and see how it goes for you.


    Since moving to the eMMC (sorry, I did a reinstall, I'm no glutton for pain so I didn't attempt to dd from the USB to the eMMC) I haven't had any kind of I/O errors when doing big transfers to the OMV box (I use my rpi as a small 24/7 torrent box/syncthing installation), which I was having intermittent issues with when using several different USB drives (of varying quality).


    I would definitely recommend it if you're like me and only expect to use the box yourself. These models of NUC can still be found for quite a good price all over ebay- you can even by the board inside and build your own little case if you're into that.


    I have yet to really figure out why the heck the CPU spikes when accessing the web-gui, but really once you've got things set up you rarely end up accessing the box through that method anyway (at least for me, I prefer to work over the command line even for updates, since I usually have a terminal open somewhere).


    Overall OMV is a wonderful and stable piece of FOSS!


    I'll fire up a couple laptops and test multi tenant performance for you this weekend, depending on my schedule.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!