Welcome, Guest |
You have to register before you can post on our site.
|
Forum Statistics |
» Members: 29,329
» Latest member: Pamax9
» Forum threads: 16,153
» Forum posts: 116,703
Full Statistics
|
|
|
Android 5.1.1 Image 20160505 wiki links |
Posted by: kinbeowulf - 05-08-2016, 03:51 PM - Forum: Android on Pine A64(+)
- Replies (7)
|
 |
Thanks for the Android images suitable for 'dd' in varoius SD card sizes. As I don't use Windows, the previous images were painfull. Some of the download links on
for the various regular and rooted Android 5.1.1 Image Release 20160505 SD card images appear to be wrong. For example, both of the 32GB microSD card links point to the same file:
21d720fa0aeaceedeef53492437539f2 android-rooted-ver5.1.1-20160505-pine64-32GB.zip
Thanks.
|
|
|
PogoPlug replacement |
Posted by: virtuallyunlimited - 05-08-2016, 01:45 PM - Forum: Pine A64 Projects, Ideas and Tutorials
- Replies (1)
|
 |
Hey everyone! Got my Pine64+ and am very pleased with the results. I am using Longsleep's Arch Linux build as I wanted something headless and light. It looks like he has stopped building arch, but I am happy with what he has done.
So my goal was to replace a Pogo plug that I had setup with the following services:
SabNZBd
SickBeard
Couchpotato
CrashPlan
MySQL
Mosquitto MQTT broker
Headphones
Samba
I used instructions from the following link to get the Pogo up:
http://blog.qnology.com/2013/03/tutorial...linux.html
I am essentially a Linux noob, but I was able to get everything going both on the Pogo and now on the Pine.
I moved to the Pine for the Gig ethernet and much faster processor. Post processing RAR files on the Pine is a much better experience.
With the Pine I picked up a 4tb USB hard drive and knocked together a really basic mounting plate for the Pine. I then just used double sided tape to attach that to the hard drive. I'd attach a pic, but it looks like I don't have those permissions.
Any all in all my new Pine is now a nice little NAS/Usenet/backup device and I am quite pleased.
|
|
|
2GB Pine won't boot up |
Posted by: belkakari - 05-08-2016, 11:21 AM - Forum: Getting Started
- Replies (1)
|
 |
I've recently recieved my pine a64+ and couldn't boot it up. I've tried remix os and ubuntu from pine wiki. There might have been some kind of electrostatic discharge, but i'm not sure. LED is bright red like everithing is ok
Is there a way to find out why the pine is not booting?
|
|
|
Mounting USB hard drive - error registering v4l2 subdevice |
Posted by: Ruckus - 05-08-2016, 10:20 AM - Forum: Ubuntu
- Replies (4)
|
 |
Hi,
I've tried a few installs of the latest ubuntu now and every time i mount an external hard drive (using a powered usb hub) i get the same error and the unit will no longer reboot properly with or without the hard drive attached.
[VFE_ERR]Error registering v4l2 subdevice No such device!
I was hoping to use my pine to replace my existing pi headless torrent seebox making use of the gigbit ethernet and faster processor but so far i've not got any use out of it at all, is this error going to be repaired in future kernals?
Thanks.
i guess the latest version of debian yeilds the same related problem. has anyone managed to get a usb hard driver to remain workable or do i have a bum board?
|
|
|
TvHeadend works beautifully |
Posted by: coleshores - 05-08-2016, 08:58 AM - Forum: Linux on Pine A64(+)
- Replies (9)
|
 |
I was previously running TvHeadend on a Raspberry Pi 2 and I bought the Pine64 strictly for headless server duty to replace the Raspberry Pi 2. The Raspberry Pi 2 was able to handle about 30 channels perfectly of 60 with the rest being very mixed success; The on the rest the was inconsistant, the audio was not syncing with the video, laggy, particularly on Standard Definition channels which was weird. I bought the Pine64 for the gigabit networking to it up as a DVR.
After switching to the Pine64, it handles all 60 channels perfectly, including the standard definiton ones as well as the ability to run DVR as far as I could tell from the last few days, hasn't skipped a beat. As far as the audio/video syncing fix I wonder if it was from compiling the TvHeadend source code to aarch64 which has better NEON optimisations at the compiler level.
Im glad you guys posted how to set up Plex as well, got that installed.
I have to say I am quite happy with the device.
|
|
|
Pine64 Cluster economy |
Posted by: baryluk - 05-07-2016, 06:05 PM - Forum: Cluster Computing
- Replies (5)
|
 |
Hi,
I was interested how the Pine64 with its very low price would stand up against other approaches. I am interested mostly in mixed CPU intensive workload. Some floating point, but also some unstructured code.
I have chosen povray, as easily available benchmark, and something that might be actually close to what I would like to test and run on pine64 cluster.
Even if results are negative I might consider pine just for distributed software development and testing. But if the economy is on a bad side, it will not make it very practical replacement for other computing platforms.
I explicitly excluded GPUs, as they are in their specific domain, will deliver best performance, both in absolute terms, and probably in perf/W and perf/$. But development for them isn't that easy and they are not suited for generic codes.
I had an access to one PINE64+ and one PC with relatively modern Intel CPU (Sandy Bridge architecture, i3930K 3.2GHz running at 4.2GHz).
Running Debian testing / unstable.
I compiled povray manually from debian sources (povray 3.7.0), with gcc 6.1 on amd64, and gcc 7.0 (custom built git version from few days ago), on aarch64. This way I got about 15% performance improvement both on Sandy Bridge CPU and on A64 SoC. Debian generic packages in testing/unstable are already compiled with -O3, but without specific -march or -mtune options to tune instruction scheduling, use cache information, etc and such.
(Note that Sandy Bridge lacks AVX and AVX2, but I doubt this would help much in this benchmark. Haswell/Broadwell might bring about 20% of generic IPC improvements, and that is the estimate I used below).
I used FDO and LTO, with final compilation using collected profiles from povray benchmark using -O3 -march=native -ffast-math -fomit-frame-pointers. I tested with other switches, but they do not bring any additional benefits or degrade performance. Most of the performance benefits are from -march=native (especially on Sandy Bridge), just a little from -ffast-math, and FDO/LTO adds few more% of improvement (but also makes binary smaller, helping with the cache utilization).
Results.
I used:
echo | time povray -benchmark
Doing standard pov ray benchmark with 512x512 target output, and adaptive subsampling, for a total of 294912 pixels, ~776k samples, ~2.63 samples/pixel. The benchmark does have very varied structure, with both simple and complex objects,. simple and complex regions, some areas with and without reflection, refraction, aniostropy, complex and simple shading, high and small spatial density of objects, mathematically complex objects and simple ones. For textured objects it uses exclusively procedural textures (including Perlin noise and other fractal methods). It puts small pressure on memory (just few megabytes of memory used at most), and small pressure on memory bandwidth (almost everything fits in the cache, and there is considerably more arithmetic and cpu code than memory accesses, also due to the lack of pregenerated textures / images).
The time below is real time passed on the main Trace pass in povray. (data parsing, data structures creation, photon time, excluded as they are only about 1% of total time, and not all are multithreaded).
i7-3930K 3.2GHz @ 4.2GHz, 32nm process, 32GB RAM: (using 12 threads)
time: 90.227 s (107.7s on debian generic build)
pixels/s: 3267
power at load: 270W (full system estimate)
power at idle: 100W (full system estimate)
minimal full system price: 450$ (estimate of minimal full system price. 8GB ram, no case, no switch. realistic)
pixels/s/$: 7.26
pixels/s/W: 12.1
Pine64 (sun50iw1p1), 2GB RAM (with small heatsink): (using 4 threads)
time: 1359 s (1949 s on debian generic build)
pixels/s: 217 (151.3 on generic build)
power at load: 6W (full system estimate including potential ethernet switch port amortized power)
power at idle: 1.5W (without ethernet)
minimal full system price: 20$ (includes PSU, cabling, heat sink, amortized price of ethernet switch port, but no cases or mounting hardware. optimistic)
pixels/s/$: 10.85
pixels/s/W: 36.17
Speculative estimate for more modern CPU:
i7-5820K 3.3GHz @ 4.2GHz, 6 core, 2x4GB RAM, 22nm process
time: 80 s
pixels/s: 3700
power at load: 250W
power at idle: 60W
minimum full system price: 550$
pixels/s/$: 6.7
pixels/s/W: 14.7
Note that I am only comparing very high end Intel cpus, with 6 cores. Comparison to i5 and i7 4 cores CPU, or AMD CPUs would make it probably considerably in favor on the x86. Both for perf/W and perf/$. I do have an access to few more CPUs, including very low power ones, and would like to update this list shortly.
Summary:
Pine64+ cluster might be realistically speaking viable alternative the x86 high performance computer in some compute intensive workloads. However, it will require about 20 Pine64 boards to match performance of the x86. But with less memory (also distributed across more devices) and memory bandwidth limits, and management + custom software overheads. To fully utilize Pine64 low price and low power usage to compute with other platforms, one needs to bring the costs as low as possible (every 1$ counts), but using shared PSU, and cheap cables and cooling solutions and DIY mounting options. Just making it cost more than 30$ will make it economically impractical. 25$ might be ok (19$ for PINE, and 6$ for different parts), 20$ would be the best.
If matched with initial cost, PINE64 might be very attractive option in the long run, due to very low idle power usage, and very high performance/W metrics.
Future work:
More tests. Calculate 2-year ownership cost at 20% utilization (20% of the time system fully loaded, 80% idle).
What do you think? Any other comparisons to make? Maybe things like webserving? memory based caching? storage of some sort?
I would love to see somebody build ~50 nodes cluster with price, performance and power details.
|
|
|
[How-To] Make PINE 64 with Ubuntu Xenial Longsleep build crunch BOINC Tasks |
Posted by: moisesmcardona - 05-07-2016, 12:00 PM - Forum: Linux on Pine A64(+)
- Replies (3)
|
 |
Hi everyone!
Yesterday I received in my mail the PINE 64 Single Board Computer I backed up a few months on Kickstarter. My Pledge was for the PINE 64 2GB edition.
First thing I did was to download and write the Ubuntu Xenial Longsleep build image to my 16GB MicroSD card (The image is almost 8GB in size). Get the Pine64 builds here: http://wiki.pine64.org/index.php/Pine_A6...re_Release
Next think I did was to boot up the PINE 64, and the first think I did once it booted up was to install BOINC:
https://www.youtube.com/watch?v=FumkMM-n...2A&index=2
However, after installing BOINC and adding some projects, I noticed they all returned a message saying there are no tasks for my current platform. The problem? The Ubuntu Xenial image is 64bit, meanwhile the projects available for the ARM architecture are made 32bit. Since BOINC reported the platform as 64bit (specifically the platform being reported is aarch64-unknown-linux-gnu), the projects didn't recognized this and returned a no work available message (because they only send work to the platform type of arm-unknown-linux-gnueabihf). Ok, so how do I make my PINE 64 get those 32bit ARM tasks? It involved using the alt_platform option and doing some stuff in ubuntu:
https://www.youtube.com/watch?v=-mmb3C5P...2A&index=3
Ok, so now I have the projects receiving tasks and the PINE 64 is crunching them as expected, except for WUProp@Home. Hmmm, seems strange that all projects I added works except WUProp@Home, so lets take a look at the workunit result:
Code: <stderr_txt>
../../projects/wuprop.boinc-af.org/data_collect_v4_4.19_arm-unknown-linux-gnueabihf__nci: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
</stderr_txt>
So as you can see, WUProp can't find libstdc++.so.6. The thing is that it IS installed, but only for the 64bit architecture and we must add the library for the 32bit architecture:
https://www.youtube.com/watch?v=t5IULP2b...2A&index=4
So there you go! We made our PINE 64 receive tasks and crunch them without any issues at all. Every task is being validated successfully So now, to enjoy our PINE 64 and let it crunch:
P.S. The PINE 64 is bigger than the Raspberry Pi's ![[Image: tongue.png]](https://cryptocointalk.com/public/style_emoticons/default/tongue.png)
![[Image: Pine64%20Added%20(resized%20for%20web).jpg]](https://moisescardona.me/files/Pine64%20Added%20(resized%20for%20web).jpg)
One last video ![[Image: rolleyes.gif]](https://cryptocointalk.com/public/style_emoticons/default/rolleyes.gif)
https://www.youtube.com/watch?v=0HCakQsQ...2A&index=5
Enjoy!!!!
|
|
|
|