ODROID-C1 – Quad Core ARM Linux computer
hardkernel.com
hardkernel.com
[1] http://hardkernel.com/main/products/prdt_info.php?g_code=G14...
I'm only getting 100-150MB/sec on rotating media today. Only 7.2K, but even 5 years ago, 10K didn't deliver that transfer speed from what I remember.
I'm getting about 100MB/sec from 3.5" Samsungs, WDs and Seagates today - but you're right according to these 4 year old benchmarks: http://www.storagereview.com/western_digital_caviar_blue_1tb...
I guess the configuration I'm benchmarking with, and the type of load, which is basically streaming, but from a journaled-but-otherwise-standard ext4, slows me down a little. But the convenience and standardness of this setup is worth more to me than a factor of 2 in performance (that's not my bottleneck at the moment).
I was investigating corruption and performance problems with our root filesystem on an SD card. The cards would be great a obvious benchmark style tasks, but when I recorded the block access pattern from our driver and replayed that on a Linux desktop with O_DIRECT, we'd not only get under 200KiB/s average access speed (which matched what we were seeing on the embedded system), but we would also get corrupted sectors (ie. we write it just fine, but we just get an error back from the card when we go to read the sector) in less than a day of sustained writes (once again at only 200KiB/s). And this was with high quality SanDisk cards that were then verified by them to be real cards (for a while we thought that clones had made their way into our supply chain). Using a weird form factor eMMC chip in an SD card got rid of these issues. There's also "industrial" SD cards that are around the same price that I suspect are basically the same thing.
That being said we tried many different SD cards from quality vendors and found pretty heavy bugs and performance related issues among all of the non "industrial" versions.
So, yes, the problems don't have to be intrinsic to the form factor, but empirically you're more likely than not to have issues with them.
http://magazine.odroid.com/assets/201412/pdf/ODROID-Magazine... (that's Dec. 2014's issue)
It's a great platform to learn on, no fuss ordering (a little waiting), and the platform is both cheap (they're one of the rare companies that has reduced the price of a product going from one release to another).
Also, the C1 beats the pants of Pi B+. :)
No complaints here.
"U-boot/Kernel/Linux source code will be released 15-Dec-2014. Android source code will be published in February after cleaning some license issues."
Looks like the biggest problem with most of these ARM boards (raspberry pi included) is the dependency on some closed-source binary blobs, at least for boot, and sometimes even the entire kernel is a closed branch off some old release.
If the GPU needs an object loaded to boot, like the RPi, that's another story. But a decent SoC should be able to start without the GPU getting in the way.
I avoid Broadcom parts anyway but that's just messed up.
I'm more skeptical of a SoC architecture that has the CPU dependent on the GPU for its startup sequence. Or is this a matter of the GPU controlling the ARM's clock tree?
I've joked before that the arm core on the rpi is really just there for power management ... and considering its share of the transistor budget, that joke almost sounds credible.
http://raspberrypi.stackexchange.com/questions/10489/how-doe...
https://www.globalscaletechnologies.com/c-14-gtimirabox.aspx
The only downside is it uses Realtek NICs instead of Intel ones. Otherwise it's pretty much perfect.
1: https://www.globalscaletechnologies.com/t-dreamplugdetails.a...
https://docs.google.com/document/d/1X9RrbkUpiTQ-S6Acken-5fv7...
AMD fanless barbone w/ dual NIC (Jetway $215) http://www.newegg.com/Product/Product.aspx?Item=N82E16856107...
SSD 64GB ($62 sandisk) http://www.newegg.com/Product/Product.aspx?Item=9SIA4UB22Z51...
4GB RAM (no ECC) ($38 gskill) http://www.newegg.com/Product/Product.aspx?Item=N82E16820231...
So, $315 and ~15W max. I bet this could serve a small office well. Someone should get this down to $200 with minimal specs (and no video or audio).
It has dual Realtek NICs; it runs pfsense and openVPN well, and you can also run squid and snort if you're into it (I haven't learned how to use them yet, but I plan to).
[1] http://www.solid-run.com/products/cubox-i-mini-computer/ [2] http://www.solid-run.com/cuboxtv/
This new chipset (S805) should also be able to support H.265 videos, the first patches for it have already appeared on the mailing list.
I can't comment on VDPAU support but for Kodi this board should be pretty awesome :)
http://the.taoofmac.com/space/blog/2013/02/10/1230
(Mine is now running Ubuntu only, and the only gripe I have is that the kernel currently lacks enough group support to run Docker - that's only a recompile away, but I like my uptime...)
The Raspberry Pi folks managed to pry documentation out of Broadcom http://www.broadcom.com/docs/support/videocore/VideoCoreIV-A..., with an FFT example included in the standard distro https://github.com/raspberrypi/userland/blob/master/host_app..., resulting in porting the Deep Belief image-recognition SDK to that GPU http://www.raspberrypi.org/more-qpu-magic-from-pete-warden/ and SHA-256 http://rpiplayground.wordpress.com/2014/05/03/hacking-the-gp...
I'd love to be able to do that kind of thing on the ODROID-C1, especially since its GPU sounds like it's a lot faster! I see that they're designed by ARM rather than Broadcom, and there's a reverse-engineering effort that has produced something of a GL implementation on them http://limadriver.org/ that has Quake 3 Arena running on it already, and faster than the binary driver, but not yet playable https://libv.livejournal.com/23886.html; but that effort seems to have stalled last year. But it sounds like it was, at the time, limited to working from reverse engineering rather than official documentation https://archive.fosdem.org/2013/schedule/event/operating_sys..., and while ARM has a lot of development documentation on their Mali site http://malideveloper.arm.com/develop-for-mali/sample-code/, none of it seems to be for the GPU itself, but rather for the OpenGL ES implementation they've written for it.
So what's the deal? Is the GPU really actually totally undocumented officially, with the only available information being a dead open-source project that produced a half-complete free-software OpenGL implementation for it by reverse engineering? Or is there more stuff out there I'm missing?
(In any case, it's pretty incredible that in 2014 you can already buy an 8-processor single-board computer that you can program for US$35.)
It's amazing running Android. The drivers are all there and it can do 1080p playback no worries. Netflix for Android runs perfectly. So does every emulator going from the N64 generation back. Easily the best box short of a media PC to connect to your TV at the moment.
It's not as good with standard Linux. The graphics drivers aren't there at all. 1080p playback doesn't really work. Example link you can read up on yourself- http://forum.odroid.com/viewtopic.php?f=83&t=3214
"When I was at Apple, I spent five years trying to get source-code access to the Nvidia and ATI graphics drivers"
That's at one of the richest development partners in the world. The secrecy is crippling.
It's not necessarily bad, but good to know for better comparison.
Heres one for around $50 http://www.buydisplay.com/default/7-hdmi-lcd-module-display-...
For $35 you can get a really decent computer. Makes it really viable for people to run a small unix dev machine or buy a bunch of these to run a miniature server farm.
[1]: http://magazine.odroid.com/assets/201412/pdf/ODROID-Magazine...
http://linuxgizmos.com/35-dollar-quad-core-hacker-sbc-offers...
Also you get a 1GBit Ethernet port, I think Raspberry has only 100MBit/s.
Of course best would be some device with low power consumption when less work is to do and which can go to full power if needed. Multiple cores would be good for that, if the device could deactivate unneeded cores or even reduce the clock speed.
I am looking forward for more power saving devices, since servers which run all the day should consume less than today.