Wandboard Quad vs CubieTruck

Thank you for the specs.  From the specs alone, it's kind of a toss-up, though I personally like the i.MX6 better because of superior documentation.  The last time I looked the AllWinner chips were documented by "confidential" documents that people "happened to find" on the Internet, which didn't have much detail.  That may have improved since I last looked.

Here would be my questions, which are directed towards anyone who has actual experience with the boards:

Has anyone reported using either or both of these as a primary computer?  That is, does either perform well enough to be able to do decent web surfing, given the horrendous inefficiency of most web sites which requires the surfing machine to have far more performance than should be required for the information content of the web sites?

How's the OS support?  Does either have an easy-to-find easy-to-download officially-recommended stable OS so users aren't confronted with a tangle of baffling contradictory suggestions like BBB?  Is either board the type where you can get Android, but if you want GNU/Linux you'd better be a kernel hacker?

How hot do the boards get?  Like Morgaine, I'm leery of chips that get hot and start to malfunction as you temperature-cycle the board.

I have an AMD-based primary computer which performs well, but it would be very nice to have a silent computer that sips power.  I'm still waiting for one that performs well enough to surf the Internet so I can quickly switch between Internet and development.  I like the idea of a Quad since several cores can be wasted on a browser when it's active, while still leaving one available for my development.  However, who knows if the OS and applications can make effective use of these cores, in which case the Dual A7 may end of working as well as a Quad A9.

John Beetem wrote:

 

Thank you for the specs.  From the specs alone, it's kind of a toss-up, though I personally like the i.MX6 better because of superior documentation.  The last time I looked the AllWinner chips were documented by "confidential" documents that people "happened to find" on the Internet, which didn't have much detail.  That may have improved since I last looked.

Tom Cubie did (possibly still does) work for Allwinner, so there's a reasonable amount of documentation available via Cubietech.  Olimex also seem to make documentation available. There are the usual missing pieces around GPU and such like. The sunxi folks are a lot closer to having decent driver support in upstream kernels than most people realise, so the necessary information is out there.

Has anyone reported using either or both of these as a primary computer?  That is, does either perform well enough to be able to do decent web surfing, given the horrendous inefficiency of most web sites which requires the surfing machine to have far more performance than should be required for the information content of the web sites?

Wouldn't be my choice, but it likely depends on what your expectations are and what sites you visit.  I've experienced websites that cause the cpu fans to speed up on a quad core Intel i7, so these javascript heavy sites are still likely to be problematic. At this time of year, those sites that use that jquery snowstorm (typically with a white background making the whole thing pointless) are particularly annoying.

How's the OS support?  Does either have an easy-to-find easy-to-download officially-recommended stable OS so users aren't confronted with a tangle of baffling contradictory suggestions like BBB?  Is either board the type where you can get Android, but if you want GNU/Linux you'd better be a kernel hacker?

http://wandboard.org/index.php/downloads  Ubuntu & Android.  http://cubieboard.org/download/ has various options. I note there's a version of Raspbian called Cubian for the various cubieboards.  Olimex typically use a Debian image, so OS choices are certainly getting better.

How hot do the boards get?  Like Morgaine, I'm leery of chips that get hot and start to malfunction as you temperature-cycle the board.

Not very in my experience. There's a large heatsink on the WBQUAD that sits just marginally above ambient - in contrast, the Sabre Lite doesn't have one at all and uses the same SoC.  The CT comes with a teeny 20x20x4mm stick on thing that's probably pointless and appears to be unnecessary. Finger test says none of these run anything like as warm as the RPi.

However, who knows if the OS and applications can make effective use of these cores, in which case the Dual A7 may end of working as well as a Quad A9.

The OS can make just as effective use of the cores as it can on your main PC. If you're going to put a desktop on one of these then the software you'll be using is exactly the same, so the question is more about whether the apps you use are any good rather than anything specific to an Arm board. Single threaded stuff is going to run more slowly simply due to the lower performance and clock these boards typically have.

I've found the quad core i.MX6 good enough at parallel compiling, with make -j 4, that there's little reason to bother with the problems of cross compiling. It's not like editing a text file is going to give any of them any problems. So for development work, much like for web browsing, it'll depend what your mix of tasks is like.

Some things are noticeably slow though. If you have anything compressed with bzip2 then it's obviously slow to decompress, and xz can be noticeably slow when compressing

Most of my usage is headless, I've yet to see any of these that can support the Dual-Link DVI connection my monitor requires and as I'm not prepared to sacrifice any screen space I don't think I'll be converting anytime soon.  However with SATA availability, I expect to convert lots of other things that currently run on power hungry x86 over to Arm based boards.

selsinork wrote:

 

I've experienced websites that cause the cpu fans to speed up on a quad core Intel i7, so these javascript heavy sites are still likely to be problematic. At this time of year, those sites that use that jquery snowstorm (typically with a white background making the whole thing pointless) are particularly annoying.

A proxy sitting on the security perimeter that strips Javascript but grabs as much of the data content of pages as possible and presents it statically for use inside the perimeter is high up on my wishlist of requirements.  The security and privacy arguments for it are colossal, and Snowden may just have precipitated that itch being scratched.

But even without that reason, the massive reduction in client-side resources needed to surf the web would be awesome for many people, and it would make low-power equipment highly usable.  It would also provide some means of dealing with the blindness of webbies who can't even display an image without using Javascript, and so web pages would be snappy again.

It would of course also make some sites completely inaccessible, such as Element14, a price to be paid by companies and users alike when their developers unthinkingly deploy such totally JS-infested software.

Morgaine.

selsinork wrote:

 

I've experienced websites that cause the cpu fans to speed up on a quad core Intel i7, so these javascript heavy sites are still likely to be problematic. At this time of year, those sites that use that jquery snowstorm (typically with a white background making the whole thing pointless) are particularly annoying.

A proxy sitting on the security perimeter that strips Javascript but grabs as much of the data content of pages as possible and presents it statically for use inside the perimeter is high up on my wishlist of requirements.  The security and privacy arguments for it are colossal, and Snowden may just have precipitated that itch being scratched.

But even without that reason, the massive reduction in client-side resources needed to surf the web would be awesome for many people, and it would make low-power equipment highly usable.  It would also provide some means of dealing with the blindness of webbies who can't even display an image without using Javascript, and so web pages would be snappy again.

It would of course also make some sites completely inaccessible, such as Element14, a price to be paid by companies and users alike when their developers unthinkingly deploy such totally JS-infested software.

Morgaine.

Morgaine Dinova wrote:

 

A proxy sitting on the security perimeter that strips Javascript but grabs as much of the data content of pages as possible and presents it statically for use inside the perimeter is high up on my wishlist of requirements.

I suspect it's an impossible task though. Too much is being hidden by libs like jquery. You'd likely need to have the proxy run the javascript which defeats a lot of the purpose.

Don't get me wrong, it's something I'd like too, I just suspect that rounding up the webbies might be a more viable option

Reminded me of http://xkcd.com/1309/

selsinork wrote:

 

Morgaine Dinova wrote:

 

A proxy sitting on the security perimeter that strips Javascript but grabs as much of the data content of pages as possible and presents it statically for use inside the perimeter is high up on my wishlist of requirements.

I suspect it's an impossible task though. Too much is being hidden by libs like jquery. You'd likely need to have the proxy run the javascript which defeats a lot of the purpose.

Oh it's definitely not possible to create a static version of a JS-infested page in the general case, as the scripting can do random obfuscation.  But a subset of scripted pages will be revealing some static names and especially the text content that matters most, maybe even some images.  As for those sites that prevent it totally --- well good riddance, there's no shortage of other sites to visit.

Don't get me wrong, it's something I'd like too, I just suspect that rounding up the webbies might be a more viable option

 

Reminded me of http://xkcd.com/1309/

Alas, they're in infinite supply.  A more viable option, at least in the case of Element14, might be to focus on the corporate angle.  Given that many engineers work in companies with firewalls and proxies for perimeter defence, the case can be made that E14 is non-operational on engineers' desktops in those places that understand that Javascript being allowed to execute deep within the perimeter is a clear security violation --- exactly the same as downloading random 3rd party executables off the net and running them.

From that angle it might be possible to get E14 management to require E14 developers to make the site work without JS as well, without the frills but retaining the most important functionality.

Unfortunately E14 devs seem to be entirely subservient to the Jive organization in this respect, so unless Jive provides an alternative path for operation without Javascript then the whole thing is doomed at E14.  If I were in their shoes, I'd either be forcing Jive development down the path of providing JS-free operation as an alternative pathway, or else abandoning Jive as not suitable for the intended audience of engineers.

Morgaine.

I just saw this post and thought I'd drop a quick note. I'll try to come back later and add more information but I'm about to run out now. I am the US Distributor of the Cubie products and have been working with them since late 2012. I don't have stock on the CT (Cubietruck) but it looks like FedEx will be delivering them on Monday (https://store.iotllc.com.

I've got a new Baseboard design that will have some nice additional features that the CT doesn't have.

Bottom line when working with any of these boards (BB, RPi, Wand) is that the board/processor can do FAR more than what software is capable of. I haven't found a magic solution that really does everything that is advertised.

Got to go but look forward to discussing more...