NativeBOINC - BOINC Client auf dem Handy/Tablet

[Dunuin]

NativeBOINC ist eine App für Andoid, welche nicht nur irgendwelche BOINC-Statistiken darstellt, sondern eure Smartphones/Tablets wirklich mitcrunchen lässt.
Die neuste Version der App findet ihr --> hier <--. Einfach aufs Handy herunterladen und dann ausführen. Ggf. dürft ihr keine Apps installieren, welche nicht aus dem Appstore stammen. Wenn die Medlung kommt einfach auf diese klicken, dann werdet ihr ins Optionsmenü geleitet, wo ihr diese Eingeschränkung deaktivieren könnt.

Danach werdet ihr durch die Menüs geführt, wobei der BOINC Client installiert wird und ihr eure Projekte auswählen könnt.

Aktuell werden nur unterstützt:

• Milkyway (milkyway_separation; optimiert für ARM)
• Primegrid (gcwsieve; optimiert für ARM)
• Enigma@Home (optimiert für ARM)
• Radioactive@Home
• WUProp

Wenn ihr die Projekte dann mit dem Handy verbindet, werden die modifizierten Projekt-Apps automatisch heruntergeladen.

Jetzt fragt ihr euch vielleicht...

1.) Macht das überhaupt Sinn mit so einem langsamen Handy?
Ich finde schon. Immerhin werden heute schon Quadcores mit 1,4GHZ verbaut, wo jeder Kern eine eigene Integer-Einheit und FPU hat. Im Vergleich zu aktuellen GPUs mag die Leistung zwar mickrig sein, aber ein Handy ist heute schneller als so manche Laptops, welche noch im Einsatz sind. Und schließlich ist jedes bischen Rechenzeit besser wie garkeine Rechenzeit.

2.) Ist das nicht zu viel Traffic für eine Handy-Flatrate?
Ihr könnt einstellen, dass da NativeBOINC nur neue WUs holt/absendet, wenn ihr mit dem WLAN verbunden seid. Das spart dann Traffic von den so genannten "Flatrates" für mobiles Internet und nutzt eure echte Festnetz-Flatrate.

3.) Ist dann mein Akku nicht ständig leer?
Wenn ihr BOINC immer unkonfiguriert laufen lasst schon. Man kann aber einstellen, dass das Handy nur rechnet, wenn es am Ladegerät angeschlossen ist. Wenn das Handy dann eh den halben Tag herumliegt, kann man es auch für die Zeit ans Ladekabel hängen, damit es sowohl laden als auch crunchen kann.

4.) Schafft das mein Handy überhaupt? Ist es kompatibel? Kommt es dann bei der Benutzung zum Ruckeln? Wird das Handy nicht zu heiß?
Das ist die Frage, welcher wir hier nachgehen wollen. Bei meinem Galaxy S3 32GB ist alles ok.

Daher meine Bitte an alle Andoid-Besitzer unter uns:
Bitte testet NativeBOINC doch mal auf euren Handys/Tablets, damit wir hier eine Liste mit kompatiblen Geräten erstellen können.

Wichtige Infos wären:

• Hersteller
• Modell des Handys/Tablets
• Firmware Version
• Android-Version
• NativeBOINC Version
• technische Daten falls bekannt (CPU, RAM etc)
• welche der oben genannten Projekt-Apps ihr probiert habt und ob die funktionieren
• gerne auch Benchmarks, also wie lange das Handy für so eine WU benötigt
• ob das Handy noch bedienbar ist, wenn BOINC läuft
• wie kritisch die Hitzeentwicklung ist
• ob es zu irgendwelchen Fehlern kommt

Ich werde dann hier im 1. Post alle Daten sammeln und sortiert auflisten. Wenn wir genug Daten gesammelt haben, dann kann ja daraus wer des Wiki-Teams mal einen Artikel zusammenbasteln.

Ein paar Impressionen von NativeBOINC:


Mit dem kostenlosen "SystemPanelLite" Taskmamanger könnt ihr dann auch z.B. die CPU-Auslastung, freien Speicher und die Temperatur überwachen:

[Uwe Sänger Herzke]

Wie wär's mit den Daten von hier:
WUProp-Ergebnisse für ARM-Geräte

P.S.: Mein S2 ist das hier:
Bei BOINCstats
Wutzen bei Milkyway und WUProp

USB-Laden geht nicht, das saugt mehr, als das Kabel liefert, es muss schon ein richtiges Netzteil sein, Auto geht aber offensichtlich.
Im Sommer, oder auch bei schlechter Belüftung von hinten, geht BOINC recht häufig in Pausemodus wegen zu heißer Batterie (konfigurierbar, von mir auf 50°C gesetzt).
Anpacken gweht trotzdem noch, da die Batterie wohl schon etwas weiter drinnen liegt, und es ganz außen etwas kühler ist, ist aber schon recht warm hinten

Die gefragten Daten liefert BOINC an den Server, hier z.B. bei MilkyWay

[X1900AIW]

Finde es klasse, falls hier im Forum/Wiki der Wissensstand einmal nachlesbar wäre. Vielen Dank @Dunuin.

Als Nicht-Besitzer enes Smartphones kann ich Null dazu beitragen. Aber diese Dinger hat doch "jeder", und v.a. Männer spielen mit so was rum (meine das keinesfalls despektierlich).

Konkrete Frage: Gibt es irgendwo eine Übersicht über empfehlenswerte Handies/Smartphones aufgrund heute bereits absehbarer Eckwerte für spätere BOINC-Tauglichkeit ?
Können gerne Auslaufmodelle sein, die es gebraucht noch zu kaufen gibt.

[Dunuin]

Meines wissens gibt es da keine. Deshalb wollte ich ja eine erstellen.

Also erste Voraussetzung für ein mobiles Gerät ist natürlich das Betriebssystem. Wenn es da keinen Boinc Client für gibt, wird das natürlich auch nichts.
Da gibt es soweit ich weiß halt nur den für Android, sofern man kein Gerät hat, wo man sich z.B. Linux draufflaschen kann.

Das 2. ist dann die CPU und dessen Funktionen. Die paar Projekte die es für Android gibt sind per Assambler auf ARM-CPUs optimiert. Ähnlich wie bei AMD und Intel mit SSE, SSE2 usw. gibt es da bei ARM auch verschiedene Befehlssätze. Nennt sich dann z.B. NEON, VFP und so weiter. Hat ein ARM-Chip z.B. keine Floating Point Unit, können die Fließkomma-Rechenoperationen nicht schnell per Hardware von der FPU ausgeführt werden. Dann muss man das langsam und umständlich über die Intergereinheit und ALU machen lassen.

Dritter Punkt dürfte der RAM und die Größe des sein Flashspeichers sein. Jedes Projekt belegt ja einen gewissen Platz im RAM und auf dem Flash (was am PC die HDD wäre). Je mehr Kerne mal hat, desto mehr WUs kann man parallel berechnen lassen und desto größer muss natürlich auch der RAM sein. Am PC hatte ich schon WUs, da gingen beim Quadcore über 3 GB RAM drauf. Am Handy habe ich beim Quadcore nur 780MB RAM zur Verfügung, wovon der Großteil schon von dem Betriebssystem verbraucht wird.
In dem Zusammenhang wäre wohl auch noch die Android-Version wichtig. Das neue Android scheint das doppelte an RAM zu brauchen wie ältere Versionen.

Hier mal ein paar Daten zu meinem S3:

Hersteller: Samsung
Modell: Galaxy S3 32GB (GT-i9300)
Preis: 580? (Stand 1. August)
Kernel Version: 3.0.15-705505-user (ungerootet)
Android-Version: 4.0.4
NativeBOINC Version: 0.3.9.9.2
CPU: Samsung Exynos 4412 (32nm 1400MHZ (in Praxis 975MHZ) Quadcore auf ARM Cortex A9 Basis mit "swp half thumb fastmult vfp edsp neon vfpv3 tls")
RAM: 1GB davon 780MB nutzbar wovon 407MB für den Kernel draufgehen. Also 373 MB nutzbar für Apps.
SD: 32GB intern (davon 25.57GB nutzbar) + optional bis zu 64GB extern über MicroSD (aber keine Apps auf externe SD installierbar)
Projekte: WUProp, Primegrid, Milkyway, Enigma@Home (grün = läuft; gelb = ungetestet; rot = fehler)
Benchmark: 4x 1180 floating point MIPS; 4x 2436 integer MIPS; Milkyway: eine WU alle 170,5 Minuten
Flüssiges Arbeiten beim Crunchen: Ja, kein Unterschied
Hitzeentwicklung: Batterietemperatur schwankt zwischen 42 und 44 Grad bei voller Auslastung aller 4 Kerne (wobei die CPU regelmäßig von 1400 auf 800MHZ runtertaktet, um die Temperatur von 44 auf 42 Grad zu senken. Im Schnitt ist CPU bei 975MHZ.)
Kommentar: Läuft soweit alles prima, auch wenn mir die CPU zu früh heruntertaktet. Das kann man zwar ändern, aber dazu müsste man das Handy rooten, wobei man die Garantie verliert. Handy muss über mitgeliefertes USB-Netzteil geladen werden, da die 500mA vom USB-Port nicht zum Laden reichen, wenn BOINC läuft.

Wenn ich den BOINC-Benchmarks glauben darf, dann steht der ARM echt gut da:
41% der FP-MIPS meines Phenom II 955BE bei 3,2 GHZ
27,5% der Integer-MIPS meines Phenom II 955BE

Ist nur schade das ARM kein OpenCL unterstützt. Sonst wäre der ARM Graphik-Chip mit 400MHZ vielleicht noch nutzbar gewesen.

Edit:
Ich sehe gerade mal wieder, man darf keine Posts editieren, welche älter als ein Tag sind. Da wirds mit dem Erstellen einer Liste im 1. Post natürlich schwer.

[Tom_unoduetre]

Ist nur schade das ARM kein OpenCL unterstützt. Sonst wäre der ARM Graphik-Chip mit 400MHZ vielleicht noch nutzbar gewesen.

Das wird aber anscheinend kommen, ich habe heute diese News auf tomshardware gelesen:

ARM: Künftige Mali-T6xx-GPUs sind OpenCL 1.1 zertifiziert

[hias]

Auch wenn der Wissensstand bei Smartphones (kann dort leider mangels Gerät nicht mithelfen) noch wenig aufgearbeitet ist kann man sich ja schonmal Gedanken machen wie es bei diesen kleinen embedded Computern aussieht (z.B. dem Raspberry etc.) und dort auch paar Daten liefern. Falls jemand sowas hat.

[Michael H.W. Weber]

Wir haben auf dem 1. RNA World Workshop im Mai bereits das BeagleBoard xM mit ARM Cortex-A8 durchgetestet.

Michael.

[Norman]

POEM hat die zusammenarbeit mit dem entwickler von nativeboinc (android) für den moment abgelehnt.

http://boinc.fzk.de/poem/forum_thread.p ... =true#6842

Hi matszpk,

thanks for the information about your project.
Unfortunately I have to tell you we are not planning to port our app to android devices at the moment.

The Android market is currently focused on smartphones and other portable devices, which are designed for long sleep phases between usage periods. I don't know how a permanently running and high demanding application will affect the lifetime of such hardware - but I guess not positively, especially talking about the battery.

Although we'd like to spread our application, this doesn't seem to be a good agreement for both us and the people who donate their computing time.

Nevertheless, I wish you good luck with your Android application, and hope you will find other projects which are interested in a cooperation.

Best regards
Thomas

[Michael H.W. Weber]

Macht nichts. Dafür wird RNA World dort einsteigen.

Michael.

[Dunuin]

So, die 4 parallelen Primegrid WUs sind nun auch durch. Bei denen muss man aber wirklich aufpassen. Deadline ist ja nur 6 Tage oder so und bei mir brauchten die WUs jeweils 4 Tage und 6 Stunden. Die letzte hatte nur noch 7 Stunden bis zur Deadline. Da sollte man lieber zu Milkyway greifen, wenn man das Handy nicht nur herumliegen haben möchte.

[X1900AIW]

In der aktuellen c´t Nr. 18 ist ein Artikel über "Smartphone-Schnäppchen" zu lesen, leider alles SingleCore, die Preisklasse von 80-170 Euro (Blackberry aussen vor) wäre als Einstieg interessant, aber zum BOINCen allein lohnt es wohl nicht. Wenn ich nun lese, dass dein QuadCore @dunuin bereits mit der dead line zu kämpfen hat ...

[Dunuin]

Ein Dualcore hätte die sicher auch schneller fertig gehabt. Ist zwar theoretisch 4x 1,4 GHZ aber in der Praxis kommt es doch nur auf knapp unter 4x 1GHZ, da immer von 1,4 auf 0,8 GHZ runtergetaktet werden muss, da die Hitzeentwicklung sonst zu hoch wäre. So ein 2x 1,3 GHZ ARM kann da vielleicht dauerhaft auf 1,3 GHZ arbeiten.

Interessant würde ich mal einen Test auf einem FPGA finden. Das ist sozusagen der neuste Schritt in der Elektronik.
Früher hat man Logik ICs benutzt, welche alle echt hardwareseitig Multitasking gemacht haben. Man konnte aber nicht schnell was verändern.
Dann sind die Microcontroller gekommen, welche mit ihrer ALU, FPU, Intergereinheit etc praktisch per Software diese Logic IC Hardware simuliert haben.
Heute gibt es die FPGAs. Das ist halt ein IC wo man über eine Programmiersprache keine HArdware simuliert, sondern sagt wie die Elektronik in diesem IC verschaltet werden soll. Lade ich ein Programm für eine C64-CPU in den FPGA, dann habe ich auf Knopfdruck eine echte C64 CPU. Keine Emulation, sondern eine echte Elektronik.
Soll der FPGA lieber ein WLAN Emfangsmodul sein...kein Problem. Neuen Code draufladen, die Elektronik im inneren verschaltet sich neu und man hat ein echtes WLAN-Modul.
So könnte man sich praktisch ICs selber bauen, welche genau das tun, was man für das DC-Projekt gerade braucht. Macht man viele Fließkommaberechnungen aber wenig Intergerberechnungen, dann lässt das FPGA-IC halt 32 FPUs, 4 Intergereinheiten und 4 ALUs bilden. Braucht ein Projekt keine Fließkommaarithmetik, dann schaltet man halt alles per Software um und hat auf Knopfdruck 1 FPU, 12 Intergereinheiten und 60 ALUs. Da sind praktisch keine Grenzen gesetzt und man kann die Hardware immer zu 100% ausnutzen, da man einfach alles weglässt, was man nicht braucht und dafür nur das bildet, was wirklich benötigt wird.
Und da es eben keine Emulation ist, arbeiten die 60 ALUs dann auch wirklich 60 Befehle gleichzeitig ab.
Deshalb sind die Grafikkarten ja auch bei Fließkommaarithmetik so schnell. Die haben halt dutzende kleine FPUs die nichts anderes können als parellel Fließkommaarithmetik zubetreiben. Anstatt wie bei der CPU mit dem einen großen Kern, der zwar alles kann, aber dafür langsam ist.
So könnte sich praktisch jedes DC-Projekt die Hardware per Code selbst zusammenbasteln, die genau auf die Bedürfnisse abgestimmt ist.
Man hat einen ARM als feste Schnittstelle zum PC oder Rounter und der ARM arbeitet praktisch als Master und sagt den angeschlosenen FPGAs, wie sie sich schalten sollen.
Jeder FPGA ist dann mit mehreren Leitungen an den Arm verbunden. Das BOINC-Projekt kann dann selbst entscheiden, was die jeweiligen FPGAs machen und wie die aussehen.

Das muss man sich wie einen Nano-Elektronikbaukasten vorstellen, wo man praktisch einen digitalen Schaltplan (in VHDL geschrieben) draufläd und die Platine sich automatisch so bestückt, dass da das entsteht, was man auf dem Schaltplan angegeben hat. Diese "Schaltpläne" gibts auch fertig zum runterladen, wenn man die nicht selbst bauen will. So ist das gleiche FPGA-IC dann z.B. eine Pentium 2 CPU, eine SD-Speicherkarte, ein C64, ein ARM Cortex, ein Amiga, ein Atmega etc.

Das hier ist z.B. so eine Bibliothek für die "Schaltpläne".