Odroid U3?

[xrad]

I think Cooper said he has one, so maybe this one is for you Cooper.

Is it fast? Looks to be way better than a rasberry pi.

Is it fairly stable?

I see there is a download called "Kali Fortress" on the odroids forum, that has everything added as opposed to the generic U2 arm at the Kali downloads.

Have you tried to install Kali?

Anything you can share about your experience with the u3?

[cooper]

I currently own a U2, the predecessor which is pretty much identical in hardware except for the fact that the U3 has one more USB port than the U2.

Size-wise, the U2 has a network connector with 2x USB in one block on the bottom, allowing a more compact setup. The U3 has the network plug separate from its 3 USB connectors, making the board wider but less high.

All USB ports are 2.0.

The CPU is a quad-core 1.7GHz Cortex A9 by Samsung which is paired on-chip with 2GB of RAM. In terms of CPU performance it puts the Pi to shame. Even the latest and greatest Pi is a single-core 700MHz part with 512MB. You do the math. I personally believe the performance is above that of a fairly recent Atom/Celeron. I started a thread here a while back investigating performance improvements to be had from picking the appropriate compiler(-options). Maybe they will help you put the device properly into perspective.

The Odroid should do equally well on the GPU front, but the Broadcom chip on the Pi has been opensourced so support for that is already decent and quickly improving. The Samsung part uses a Mali GPU which is ARM proprietary technology. Luc Verhaegen a.k.a. libv is working on reverse engineering a driver for it but after progressing by leaps and bounds in 2012 last year most of the work was done in driver plumbing so it's not really visibly progressing. One of the consequences of this is that up until now there is no XV support in the XFree driver for this chip which really hurts on the media playback front. I believe this problem goes away when you run Android on it as apparently they do have some closed-source drivers for the chip.

Stability is rock-solid. Check out that benchmark thread. I'm running a huge compile and follow that up by running POVRay on all 4 cores. Worst that happened was a bit of thermal throttling, which thus-far I've found takes considerable effort.

The problems I've encountered so far are:

- On newish kernels (3.8.18 or thereabouts) audio via the headphone jack stopped working. No problem with audio over HDMI.

- The network adapter works off of the USB 2.0 bus which is why it's capped at 100MB/s and also why streaming a movie over the network can load one core up to 60% processing all the USB interrupts. Since the keyboard is plugged in via USB aswell it can make your keyboard input lag considerably. For most people though this is "good enough".

- Depending on wether or not you have a sufficiently new screen (mine is downright ancient) you may experience 'overscan', which means that about 20 pixels on all sides of the screen end up off-screen, like you scaled just a tad too far. This has something to do with the chip used so no fix is forthcoming. I solved it by going with a windowmanager that allows you to restrict windows to within a certain frame which is set appropriately. Works without a hitch.

Never tried Kali on it or any other system. I'm most comfortable with Gentoo so I installed that. Had to roll my own, but that's kinda how I like it. The bootloader you're required to use, u-boot, is sufficiently similar to Grub to be workable. Since about 6 months now you get the boot console on the screen (used to be wait and keep your fingers crossed until X appeared) and HDMI-CEC is supported although I don't know what it's supposed to be doing.

When you buy an Odroid you can also get an eMMC card for storage. Alternative is to get a MicroSD card. You'll need one of them. Comparing the two is like comparing SSD with 50.000 little china men in your basement shouting '1' or '0' up at you. When you think disk IO performance is relevant in your usage scenario (and I felt that a media player needed this, so I got one for my U2 but will use MicroSDs for my cluster) you should DEFINATELY go with the eMMC. Don't lose the fib you get with it that allows you to access it via a MicroSD cardreader.

Forum member Robroy provides a pretty full stack of images prepopulated with various programs for all sorts of usage scenarios.

If you do choose to get one, remember that they are shipped via FedEX from North Korea which in my case means I pay upwards of half the price of an Odroid in shipping and then the taxman appears at my doorstep asking a 20% import tax or whatever. I've been told that shipping to the US is considerably simpler and cheaper. What I'll have to give the FedEX route, though: It's fast. Within a week you have your product. Due to complaints about the high cost of shipping and other issues with FedEX basically being a bunch of assholes the folks at HardKernel are considering shipping via either DHL or even standard airmail. Nothing concrete appears to have been decided on that point just yet though. The thread on this topic is here.

Anything else, feel free to ask. :-)

[cooper]

Couple of things I forgot to mention.

- Both the U2 and the U3 will operate reliably fanless in a sufficiently ventilated area. I have my U2 on the carpet in the roughly 5cm gap between the floor and the underside of the cupboard my tv sits on. There is ZERO airflow but the space is open around all sides so that's how the heat can get away. This works just fine.

- If you do get a little worried about the heat, they sell (but due to shipping I think it's cheaper to buy locally) small 4cm fans that you can attach to the heatsink. There's some sort of 2-pin connector for one on the boards.

- Apparently the chip can be trivially overclocked in software to 2GHz. I haven't tried this myself, no idea how this influences heat buildup or improves performance. I typically run it using the ondemand governor which tends to mean 3 cores offline and 1 at, like, 400 MHz or something. Note that certain pieces of software such as ffmpeg will create as many threads as they see cores on startup (unless you explicitly tell it otherwise) so either write a quick shell script to set the governor to performance before starting ffmpeg or a similarly quick wrapper script to ffmpeg which forces it to use a specific number of threads (I always say 3 since I need core #4 for the network streaming work).

- You can run any full-fledged browser on this, but if you *must* have Flash your only option is Chrome's own PepperFlash thingy as that's the only flash runtime available for ARM. They only distribute this as part of their Chromebook software offering so it's a bit tricky to find. Look in the ArchLinux repository for directions to a download of this but know that it's likely to be illegal for you to have this software and not a Chromebook. With the proliferation of HTML5 this problem is slowly going away.

- You get the best (and in fact rather impressive) performance when the code you run has been NEON optimized. NEON is like ARM's version of MMX. There are such optimized routines in ffmpeg for decoding a video stream to for instance YUV420, but NOT for the conversion of YUV420 to the displayable RGB888. Because of this and the X.org driver issues the Odroid spends an inordinate amount of time converting the video and because of that has a hard time keeping up with a 1080p stream. It's doable, particularly when the data is stored locally as opposed to streamed via the network. When someone does create these routines in ffmpeg I'm sure there will be much rejoicing. My own "HD ready" TV turned out to be 720p as far as the screen goes and working at that size things tend to go just fine. The non XV driver thing means that scaling up, another unoptimized function, hurts. You can set the scaling function to linear, which is one of the fastest that to my eye still looks good, to alleviate this to the highest extent.

If you choose to get one of these as a portable hacking platform, the best of luck to you. They're roughly as power-hungry as a pineapple without any antenna attached. On the other hand, if your biggest gripe with the pineapple is performance and you have one or two wifi adapters with interesting chipsets in them, then yeah, this could definately work. But if you're going to transmit 1W of power, you're going to have to bring a big battery to the party aswell. In fact, I would highly recommend getting a powered hub for this scenario. And no, you can't get the Odroid to acquire its power from USB like you can with the Pi, in part because the USB spec says max power draw on a single connection is 0.5A and the Odroid can need quite a bit more in certain scenarios. I have a USB harddisk that tries to run fully off of USB power and while my laptop has no issues the Odroid just dies trying to power it.

Edited May 16, 2014 by Cooper

[xrad]

Thanks Cooper, your wealth of knowledge and your perspective on things, is always helpful.

I'll ask here if I have any other questions.

The XU looks really good too, 4xUSB 2.0 and 2xUSB 3.0, 8 cores, but I see it is about at its eol.

I guess was just to much money for tinkering, and they didn't sell many.

[cooper]

Are you kidding me? The XU is the new one, only on the market since last August. This puppy is a lot of things but most certainly NOT EOL.

It's a cool board, with the 8-core Exynos5 in big.LITTLE configuration - this chip has 4 A7's and 4 A15's. The A15 cores are approx. 40% faster clock-for-clock compared to the A9 but they draw considerably more power. When load is light the chip scales down to the 4 A7s which are, like, ultra low power and performance (and apparently it's physically impossible to use all 8 cores at once). This chip powers the Google Nexus 10.

Main drawback? A price tag just shy of 170 bucks. You can get almost 3 U3s for that amount of money.

Note that the XU uses a PowerVR graphics part instead of the Mali you get with the U3. It would appear the PowerVR is much better supported by Linux.

And just so you know, since these are development boards HardKernel only guarantee availability for about 1 to 1.5 years. After that they tend to introduce a replacement part and you simply won't be able to buy the old ones anymore unless you buy in considerable bulk. One guy got bitten in the arse by this as he had designed a device around the U2 and they changed the size on him with the U3 at about a moments notice. They've since promised to both announce any upcoming changeovers when an old device goes EOL and its replacement part will be the new deal, plus they're going to try to retain the board dimensions if at all possible and if it's not they will inform people beforehand that the change is coming and what exactly it will entail. We'll have to see it happen first, though.

Edited May 16, 2014 by Cooper

[xrad]

Ahhh.........it's the XU-Lite they are discontinuing, my bad.

I leaning toward the XU right now.

A bit pricey.