Gestatten, das CubieNAS...

[Thomas Kaiser]

Darf ich vorstellen: ein Gbit-fähiges Multiprotokoll-Multimedia-NAS
(inkl. zigtrialliarden möglichen Add-Ons) mit 4 TByte HD, Anschlüssen
wie Sau [1], kaum Leistungsaufnahme, per PoE [2] befeuerbar, in zeit-
losem MDF-/Kabelbinder-Chassis und natürlich lüfterlos/lauwarm für ca.
270,- € brutto [3]. Mehr als die Hälfte der Kosten verschlingt leider
die Verbauung einer bzw. eben der 3,5"-HD:

http://kaiser-edv.de/tmp/9nQgUX/front.jpg
http://kaiser-edv.de/tmp/9nQgUX/front-schraeg-von-oben.jpg
Im Bild: PoE-Eingang, oben USB-Hub, Mitte Cubietruck-Anschlüsse
(VGA, S/PDIF, HDMI, Ethernet, Strom), unten sanft gelagerte Fest-
platte

http://kaiser-edv.de/tmp/9nQgUX/back.jpg
Im Bild: oben die Spannungswandler-Platine, rechts oben PoE-
Ausgänge, Mitte Cubietruck-Anschlüsse, unten HD

Die Basis ist das Cubietruck, also sowas wie ein Rasperry Pi, nur zwei-
mal so groß, gut dreimal so schnell und mindestens viermal so toll [1].
Das Cubietruck-Kit kommt bereits mit allen Kabeln, drei vorgebohrten
Plexiglas-Scheiben und Abstandshaltern. Wer das Ding mit einer 2,5"-
HD/SSD nutzen will, kann gleich loslegen -- da ich eine 3,5"-HD nutzen
wollte, hab ich ein kleines Spannungswandler-Board mitbestellt (das will
12V in, hat 12V out, die man zur HD durchschleift, und stellt per USB 2
x 5V bereit, die dazu reichen, das Cubietruck selbst und bspw. wie in
meinem Fall noch einen aktiven USB-Hub zu versorgen). Die 12V kommen
entweder per Netzteil. Bei mir jetzt per PoE -- ein TL-POE10R wandelt
die dort anliegenden 48V runter.

Ich will das Ding eigentlich gar nicht wirklich als echtes NAS nutzen
sondern eher so als _der Gerät_ 2.0 [4]. Aber da es sich ja lohnt,
Erfahrungen zusammenzuschreiben, und das ein einigermaßen häufiger
Einsatzzweck sein könnte, anbei die Tauglichkeit als NAS-Device.

Vorab aus Mac-Nutzer-Perspektive: Was kann das Ding? Alles, was die
aufgespielte Software eben so kann. Die chinesischen Entwickler des
Boards stellen fix und fertige Images bereit, mit der die Installation
auf der dann doch bissi exotischen ARM-Hardware zum Kinderspiel wird
[5]. Das Cubietruck kommt vorinstalliert mit Android (wegen QA). Will
man das nicht, installiert man eben was anderes. Ich hab mich für
lubuntu-desktop auf den internen 8 GByte Flash entschieden [6]. Anschl.
hat man dann ein Linux (Linaro 13.04, Ubuntu/Debian-basiert, Kernel
3.4.61+ armv7l), das sich Debian-like bändigen läßt (apt-..., dpkg,
etc.)

Zur Performance:

1) iperf: ohne irgendwas zu tunen ist das Maximum so um die 450/550
MBits/sec (TX/RX). Das ist bisserl mehr als die Hälfte des über
GBit-Ethernet Möglichen und liegt wohl daran, wie der RTL8211E-NIC an
den Chipsatz angebunden ist (die CPU hatte jedenfalls noch Luft und
für "NIC hinter USB" ist die Performance zu gut).

2) LanTest gegen Netatalk 3.1 [7]: Nach Umbiegen der CNID-Datenbanken
weg vom NAND-Flash auch auf die 3,5"-HD ("vol dbpath"-Option) nach
wie vor schreibend bescheidenste Performance (lesend ist OK):

http://kaiser-edv.de/tmp/9nQgUX/Bildschirmfoto%202013-11-23%20um%2021.16.55.png

Hmm... hab die HD mal mittels bonnie++ vermessen:

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
Cubie mit WD Gr 10G 71 98 36917 41 19304 27 357 98 146447 88 169.9 25
Latency 340ms 1917ms 212ms 48022us 52600us 707ms
Version 1.96 ------Sequential Create------ --------Random Create--------
Cubie mit WD Green -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 5513 59 +++++ +++ 7163 73 6535 84 +++++ +++ 7388 78
Latency 16104us 3037us 18404us 13167us 154us 7072us

Auch nicht berauschend. Aber lustig bzw. gut: Während der Streßtest
läuft, blinkt das Ding vor sich hin wie die wilde Angst. Aber man hört
so gut wie nichts. Wenn ich das Trum komplett unters Sofa schiebe, hör
ich zumindest auf dem Sofa sitzend genau gar nichts mehr, d.h. Schritt 2
(den MDF-Mist in eine EMV-freundliche Blechkiste mit Schalldämmmatten
verbauen) kann ich mir vermutlich sogar sparen :-)

http://kaiser-edv.de/tmp/9nQgUX/2013-11-23%2022.31.42.mov

Gruss,

Thomas

[1] Cubietruck-Details:

AllWinnerTech SoC A20-Plattform mit Cortex™-A7 1Ghz Dual-Core
ARM®-Prozessor mit integrierter Mali 400-GPU, 2 GB Ram, 8 GByte
internem NAND-Flash

Anschlüsse: HDMI (1080p) und VGA, Gbit-Ethernet (RTL8211E), WiFi,
Bluetooth, SATA 2.0-Interface, microSD-Slot, zigmal USB, S/PDIF, IR,
Kopfhörer und über 54 Spezial-PINs alle gängigen Bus-Schnittstellen

http://linux-sunxi.org/A20-Cubietruck
http://docs.cubieboard.org/products/start#cubietruck_cubieboard3

[2] PoE: http://de.wikipedia.org/wiki/Power_over_Ethernet

[3] Teileliste des CubieNAS in rustikaler MDF-Ausführung:

- Cubietruck Kit à 89,-
http://www.exp-tech.de/Mainboards/ARM/Cubietruck.html

- 3.5 inch HDD addon package à 10,-
http://www.exp-tech.de/Shields/Strom-Spannung-79/3-5-inch-HDD-addon-package-for-Cubieboard-Cubietruck.html

- Datengrab: WD Green mit 4 TByte à 139,-
http://geizhals.at/de/western-digital-wd-green-4tb-wd40ezrx-a997945.html

- TL-POE10R POE Splitter à 12,-
http://geizhals.at/de/tp-link-tl-poe10r-poe-splitter-a417887.html

- Logilink USB 2.0 Hub 4-Port-Hub à 7,-
http://geizhals.at/de/logilink-usb-2-0-hub-schwarz-ua0085-a552450.html

- Teile für DIY-Gehäuse aus dem Baumarkt + Kabelgedöns exakt 12,82

[4] Das Cubie ist bei mir jetzt in die nähere Wahl gerückt nachdem ich
bisserl mit einem RasPi rumgespielt habe aber parallel noch die
Notwendigkeit für Backup-Device aufgekommen ist. Die Cubies können
SATA und das neue Cubietruck hat auch gleich den ganzen
Multimedia-Schnickschnack an Bord. Insofern ist das grad die
experimentelle Spielwiese, um in Personalunion die Thematiken
Backup, Multimedia und Monitoring/Home-Automation anzugehen.

Das Ganze ist aber mindestens zur Hälfte reines Spielprojekt, da bei
uns beruflich grad das Thema Monitoring einen recht hohen
Stellenwert erlangt und die Kombination von irgendsoeinem
Billig-Schraddel wie RasPi & Co. nebst per GPIO angebundenen
Sensörchen auch das Monitoring von physischen Randbedingungen
drastisch günstiger/flexibler macht im Vergleich zu Etabliertem.

Aktuell soll das Cubie also mindestens mal das da machen:

Multimedia/Mediacenter:

- XBMC-fähig (und damit Airplay)
- S/PDIF direkt onboard (und nicht wie beim RasPi nochmal per
externem USB-Interface)
- DVB-T-Stick, der eh noch rumliegt, optional nutzbar
- Dank Cubies onboard-IrDA sowohl per Fernbedienung als auch per
iGadgets steuerbar

Home-Automation (bzw. Spielwiese RZ/Server-Überwachung):

- Auslesen Sensordaten, bspw. Temperatur/Feuchtigkeit: DHT22/AM2302
- USB-Steckerleisten schalten, konkret http://geizhals.at/de/gembird-energenie-eg-pms-6-fach-a732667.html
- AB440-Funksteckdosen schalten
- USB-Webcam netzwerkfähig machen

Backup-Device:

- NFS-Share für Backups von VMs, die auf einem Mac Mini laufen
- TM-fähig Dank Netatalk (wird hier allerdings nicht genutzt werden)
- repliziert die Backups auf zweites Device (RasPi-basiert) im Büro

Apropos "der Gerät"... ich mein das da: http://www.stupidedia.org/stupi/Der_Gerät

[5] http://docs.cubieboard.org/tutorials/cb3/start

[6] Will man Images auf dem internen NAND-Speicher des Cubie
installieren, braucht man ein Image (siehe [5]). Hat man so ein
Image, dann braucht man am Mac noch LiveSuit
([http://cubieboard.org/download/]). Und das Prozedere mit dem
Cubietrack ist dann extrem simpel: Cubietruck stromlos machen,
LiveSuit starten am Mac, Image auswählen. Jetzt nur am Cubietruck
seitlich die FEL-Taste drücken und dann Mac und Cubie per USB-Kabel
verbinden (am Cubie den "USB OTG"-Mini-Anschluß nutzen). Die
USB-Verbindung versorgt den Cubie mit Strom. Und wenn auf dem Mac
nix USB-seitig hereinfummelt (wie bspw. Virtualisierer -- ich hatte
erst Erfolg, nachdem ich VMWare Fusion gestoppt hatte), dann wird
das Image binnen Minuten auf den internen Speicher geflasht. Anschl.
startet sich das Cubie neu und im Fall des fertigen Lubuntu-Images
kommt man dann per linaro/linaro auf die Kiste.

Noch was ist erwähnenswert für Mac-Nutzer: Das kleine Cubie ist eine
Zicke, was HDMI-auf-irgendwas-Adapter angeht (zumindest die von
Apple). Ich hatte erst was anderes als "schwarzer Bildschirm" als
ich das Cubie HDMI-nativ an den Beamer gehängt habe (maximal
entwürdigender Installationsvorgang, weil Beamer-Kabel sehr kurz,
unter Sofa kein Licht, Kaiser kurzsichtig und dann irgendwann mit
Stirnlampe teils unter Sofa, teils gegenüber an Leinwand, um das
Kleingedruckte zu entziffern)

[7] Ich hab mal mit Netatalk 3.1 getestet. Also ausgehend von
http://netatalk.sourceforge.net/wiki/index.php/Install_Netatalk_3.0.6_on_Debian_7_Wheezy
einfach vorab per apt-get noch libtracker-sparql-0.14-dev geholt
(für Spotlight-Suche _in_ Dateien) und dann wie im Netatalk-Wiki
beschrieben den üblichen Dreisprung configure/make/"make install"
durchgeführt. Klappte auf Anhieb. Und nach bissi Feintuning der
afp.conf dann auch erste Tests möglich

[frid...@gmail.com]

Hallo Thomas!

Klingt interessant.... hast du schonmal versucht, OMD (http://omdistro.org) oder Nagios/Icinga drauf laufen zu lassen zwecks Monitoring? (Dafür ist der RasPi leider zu schwach auf der Brust und wurde deshalb bei uns zum reinen "Displaytreiber" degradiert, der nur noch die OMD/Wato/Check_MK-Webpage anzeigt auf einem Fernseher)

Ciao, Frido.

[Thomas Kaiser]

frid...@gmail.com schrieb in <news:4efda308-651d-420f...@googlegroups.com>

> Klingt interessant.... hast du schonmal versucht, OMD (http://omdistro.org)
> oder Nagios/Icinga drauf laufen zu lassen zwecks Monitoring?

Nö. OMD kommt quasi schlüsselfertig [1], das werde ich mir demnächst mal
anschauen (aber wohl eher in einer separaten VM auf 'nem Mac Mini). Mein
Monitoring-Ansatz ist eh ein anderer. Die 1-Platinen-Knechte à la RasPi
oder Cubie sollen wenn dann Daten sammeln und an eine zentrale openNMS-
Instanz verfüttern (Temperatur/Luftfeuchte, Kontakt bspw. Tür, etc.). Im
selben Kontext dann auch PoE-Werte per SNMP vom versorgenden Switch
auslesen und ins Monitoring einfließen lassen und sowas.

> Dafür ist der RasPi leider zu schwach auf der Brust

Da das Cubie wohl ansatzweise hält, was es verspricht (bzgl. Netzwerk-
durchsatz Korrektur in [2]), fliegt der RasPi hier jetzt raus bzw. kommt
ins Büro. Stromversorgung per USB-Port der dortigen Fritzbox und am
RasPi per USB

- "programmierbare" Steckerleiste EG-PMS2 <http://tinyurl.com/op6jkmw>

- 6 TByte lahmer Backup-Speicher in Form 2er 3 TByte-HDs in einem
IB-RD4320StUS2 [3]

Steht ein Backup an, dann schaltet der RasPi per USB via sispmctl
<http://sispmctl.sourceforge.net> das externe USB-Gehäuse an, wartet per
lsusb, bis das Ding hochgefahren ist, hängt dann die Partition ein,
sichert, hängt das Dateisystem wieder aus und knipst abermals per
sispmctl den Strom wieder aus. Über 2 andere Stromkreise wird der Rest
des Elektro-Zoos dann ebenfalls via RasPi überwiegend stromlos gehalten
bzw. der eine Teil des Equipments automatisch eingeschalten sobald sich
Herrchen nähert (ping auf die IP-Adressen von MacBook und Smartphone)
und Drucker bei Bedarf (sispmctl hat ein Webinterface, das man per curl
befutteln kann -- ich denke, dass ich die Drucker dann direkt aus CUPS
am Mac heraus einschalten lasse)

Damit ist im Büro dann in Abwesenheit nur noch 1 Steckernetzteil mit
Fritzbox und RasPi dran aktiv, der Rest komplett aus.

Gruss,

Thomas

[1] Ein "deb http://labs.consol.de/repo/stable/debian wheezy main" nach
/etc/apt/sources.list.d/omd.list geworfen, GPG-Key importiert
(<https://labs.consol.de/repo/stable/>) und "apt-get update"
hinterher... und schon findet ein "apt-cache search omd" den Kram.

linaro@cubietruck:~> apt-cache show omd-1.00
Package: omd-1.00
Version: 0.wheezy
Architecture: armhf
Maintainer: OMD-Team <deb...@omdistro.org>
Installed-Size: 242704
Depends: debconf (>= 0.5) | debconf-2.0, time, traceroute, curl,
dialog, dnsutils, fping, graphviz, libapache2-mod-fcgid,
libapache2-mod-proxy-html, libboost-program-options1.49.0,
libdbi-dev, libevent-2.0-5, libgd2-xpm, libltdl7, libnet-snmp-perl,
libpango1.0-0, libperl5.14, libreadline6, libsnmp-perl, libuuid1,
libpython2.7, mysql-server, patch, php5, php5-cgi, php5-cli,
php5-gd, php5-mcrypt, php5-sqlite, php-pear, rsync, snmp, unzip,
xinetd, xvfb, python-ldap
Filename: dists/wheezy/main/binary-armhf/omd-1.00_0.wheezy_armhf.deb
Size: 75541294
MD5sum: f20d30009f2d0223957c249bb6613218
SHA1: 25268f679fb0dbdbf7f61a3bd609ebd458fc8b82
SHA256: 04a1f1f5f9e115687f36ef20c1864b5ff9c3baf409f6fa57d5b35564fe33e2f4
Section: admin
Priority: optional
Homepage: http://www.omdistro.org
Description: Open Source Monitoring Distribution, containing Nagios,
the Nagios plugins, Check_MK, Livestatus, Multisite,
PNP4Nagios, NagVis, and other addons. Please visit
http://omdistro.org/.

Nett, die ARM-Plattform gleich voll unterstützt :-)

[2] Meine LanTests gestern fanden von virtualisierten OS X Instanzen
statt und offensichtlich ist da irgendwas nicht ganz sauber. Heute
nochmal getestet mit physischem 10.8.5: ca. 29/42 MByte/sek
(schreibend/lesend).

Die iperf-Tests habe ich jetzt mit 3 parallel laufenden Clients
wiederholt. Dann geht in Summe mehr aber letztlich ist die lahme CPU
in Verbindung mit besch***enem RealTek-NIC dann schuld, dass das
Cubie abriegelt:

3 Clients Richtung cubie: 850-860 Mbits/sec (0%-2% idle)
Cubie Richtung 3 Clients 630-638 Mbits/sec (5%-10% idle)

[3] http://www.raidsonic.de/de/products/soho-raid.php?we_objectID=6856
Fehlkauf gewesen, denn die eSATA-Chose funktionierte im angedachten
Setup nicht und die Performance per USB 2.0 ist grottig. Für den
angedachten Sicherungszirkus aber völlig schnurz bzw. ausreichend.

[frid...@gmail.com]

Anscheinend haben wohl schon Leute OMD auf irgendwelchen Android-Tablets laufen lassen, die ja hardware-seitig nicht so weit weg vom Cubie sind.

OMD ist hier bei uns im Einsatz, funktioniert auch einwandfrei (auch in einer VM), dürfte nur je nach Anzahl der überwachten Services/Hosts irgendwann an Netzwerk-/CPU-Grenzen stoßen (in unserer Konfig mit 4000 Services/400 Hosts zieht es schon ein wenig)

Bin mal gespannt, was deine weiteren Experimente bringen (sispmctl klingt recht interessant, wenn ich dran denke, was uns Dienstleister im Windows-Bereich für so eine Steckdose abgeknöpft haben :-(

Danke für deinen Bericht!

Ciao, Frido.

[Thomas Kaiser]

frid...@gmail.com schrieb in <news:0426c4a2-c18b-49e5...@googlegroups.com>

> Anscheinend haben wohl schon Leute OMD auf irgendwelchen
> Android-Tablets laufen lassen, die ja hardware-seitig nicht so weit
> weg vom Cubie sind.

Hmm... ich glaub, dass auch das Cubietruck im Vergleich zu gängigen
Tablets eher untermotorisiert ist. Eine interessante Alternative könnte
noch das Nitrogen6x sein (Quad-Core A9, ebenfalls SATA, GBit-Ethernet):)

http://www.module-store.com/de/Evaluation-Boards/freescale-i.MX6-Quad-Core/Nitrogen6x-freescale-i.MX6-Quad-low-cost-Entwicklungsboard

Aber nur halb so viel RAM und mehr als doppelt so teuer (dafür kann's
gleich PoE).

> Bin mal gespannt, was deine weiteren Experimente bringen

Wieder im eigentlichen Kontext NAS: Die verbaute 4 TB-Platte legt sich
nun brav schlafen, dann ist die Kiste absolut lautlos und zieht kaum
Strom (wenn nix zu tun ist, taktet sich der A20 offensichtlich auf bis
zu 144 MHz runter und senkt die Core-Spannung auf unter 1V). Ich hab
jetzt in der /etc/hdparm.conf das da stehen (denn eigentlich würde man
ja die UUID der Platte angeben aber da gibt's wieder irgendeinen Ubuntu-
Bug, der dann den automatischen Spindown nie eintreten läßt):

/dev/sda {
spindown_time = 120
}

Und nach der vorgegebenen Zeit wird's mucksmäuschenstill und ein "hdparm
-C /dev/sda" meldet dann auch brav "/dev/sda: drive state is: standby" :-)

Ich hab heute mal versucht, anzutesten, ob der SATA-Port des A20 auch
mit Port-Multipliern zurechtkommt (dann könnte man mit dem einen Cubie
ggf. 'zig HDs bereitstellen, von denen dann freilich nicht alle gleich-
zeitig anlaufen sollten, wenn man nur mit 'ner schwachen Stromquelle am
Start ist)

http://kaiser-edv.de/tmp/9nQgUX/eSATA-Portmultiplier-Versuch.jpg

Hat nicht geklappt, was ich aber dem externen Gehäuse anlaste. Wenn das
im RAID-Modus unterwegs war, dann kam im Log auch brav

ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
scsi 0:0:0:0: Direct-Access ATA JMB352 RAID-0 n/a PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 11721066304 512-byte logical blocks: (6.00 TB/5.45 TiB)

Aber bei NRAID oder JBOD tauchte dann immer nur eine Platte auf (weit
und breit kein /dev/sdb):

scsi 0:0:0:0: Direct-Access ATA ST3000DM001-9YN1 CC4B PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)

Und wirklich stabil war das Ganze auch nicht, nach kurzer Zeit dann
regelmäßig

ata1: hard resetting link
ata1: SATA link down (SStatus 0 SControl 300)
ata1: limiting SATA link speed to 1.5 Gbps

Aber ist halt auch nur ein schrottiger JMicron JMB352 im Gehäuse und
eine bekanntermaßen zickige SATA-eSATA-Verbindung. Versuch ohne Ergebnis
abgebrochen -- mal weiterhin im Netz beobachten, was andere diesbzgl. so
herausbekommen...

Nächste Tests stehen noch aus. Die WD Green mal an potenter Hardware
vermessen bspw. (aber genau die Kiste zickt grad rum). Ich mach dann
nochmal die Ingrid, wenn ich diesbzgl. mehr Klarheit habe.

> (sispmctl klingt recht interessant, wenn ich dran denke, was uns
> Dienstleister im Windows-Bereich für so eine Steckdose abgeknöpft
> haben :-(

Aus _der_ Ecke kommt auch die Initialzündung für diese Spielerei. Hab
bei 'nem Kunden ein Angebot rumliegen gesehen, das bisserl "physisches
Monitoring" umfaßte (bspw. SNMP-fähiges Thermometer), im 4-stelligen-
EUR-Bereich lag und die Neuanschaffung eines Switches notwendig machte
(weil jedes Trum seine eigene RJ45-Buchse aufweist). Aber wie schon
geschrieben: Im Moment alles reine Spielwiese bzw. "Evaluierung" ;-)

Gruss,

Thomas

[Gerald E:scher]

Thomas Kaiser schrieb am 23/11/2013 22:52:

> Darf ich vorstellen: ein Gbit-fï¿œhiges Multiprotokoll-Multimedia-NAS
> (inkl. zigtrialliarden mï¿œglichen Add-Ons) mit 4 TByte HD, Anschlï¿œssen

> wie Sau [1], kaum Leistungsaufnahme, per PoE [2] befeuerbar, in zeit-

> losem MDF-/Kabelbinder-Chassis und natï¿œrlich lï¿œfterlos/lauwarm fï¿œr ca.
> 270,- ￜ brutto [3]. Mehr als die Hￜlfte der Kosten verschlingt leider

> die Verbauung einer bzw. eben der 3,5"-HD:

Nett.

> [7] Ich hab mal mit Netatalk 3.1 getestet.

Bitte einen Bericht, wie das Kistchen als TM-Server performt.
Andernfalls wirst du wegen OT-Posterei mit einem nassen Fetzen verjagt
;-)

--
Gerald

[Thomas Kaiser]

Gerald E:scher schrieb am 25.11.2013 in <news:20131125232536....@ID-37099.user.uni-berlin.de>

> Thomas Kaiser schrieb am 23/11/2013 22:52:
>

>> Darf ich vorstellen: ein Gbit-fähiges Multiprotokoll-Multimedia-NAS

>> (inkl. zigtrialliarden möglichen Add-Ons) mit 4 TByte HD, Anschlüssen

>> wie Sau [1], kaum Leistungsaufnahme, per PoE [2] befeuerbar, in zeit-

>> losem MDF-/Kabelbinder-Chassis und natürlich lüfterlos/lauwarm für ca.

>> 270,- € brutto [3]. Mehr als die Hälfte der Kosten verschlingt leider

>> die Verbauung einer bzw. eben der 3,5"-HD:
>
> Nett.
>
>> [7] Ich hab mal mit Netatalk 3.1 getestet.
>
> Bitte einen Bericht, wie das Kistchen als TM-Server performt.

Gemach, Gemach. :-)

Ich will's diesmal sauber angehen und arbeite mich mal von unten nach
oben vor. D.h. zuallererstmal lokal die Grenzen der Platte (und deren
auf dem Cubie zur Verfügung stehenden Features ausloten [1]), dann
vergleichen mit bekanntermaßen sauber funktionierender Hardware (bei mir
ein Shuttle SX58J3) und herausfinden, an welcher Stelle es klemmt. Und
wo vorhanden, Lösungen finden/dokumentieren. Die verbaute Platte sollte
theoretisch schneller als GBit-ENet sein, dito das im Cubietruck
verbaute SATA-Interface (da haben Leute mit 'ner SSD sowohl lesend als
auch schreibend deutlich über 100 MB/sec gemessen)

Bzgl. LAN zeichnet sich aber jetzt schon ab, daß Gbit-Ethernet von nur
_einer TCP-Session_ wohl nicht ansatzweise saturiert werden kann:

http://en.wikipedia.org/wiki/Cubieboard#Cubietruck

Der RTL8211E bürdet der CPU 'ne Menge Last auf, stellt sich ziemlich
quer, wenn man ihm mit ethtool kommt, und beherrscht offensichtlich noch
nicht mal Jumbo Frames :-(

Ich melde mich mit Details -- aber das wird jetzt bisschen dauern. Und
apropos OT: Ich versuch mich mit maximalem OS X Bezug hier. Nächster
Schritt ist eine Modifikation der Script.bin-Datei (weil das Cubie auch
wenn es nichts tut konstant eine Load von 1 hat, was mit irgendeinem
USB-Modus zu tun hat). Außerdem kann man dem Ding auf dem Weg eine fixe
MAC-Adresse verpassen. Dazu braucht's dann aber bin2fex/fex2bin:

http://linux-sunxi.org/Sunxi-tools#phoenix-info

Und was davon am Mac läuft bzw. wie man sich verrenken muß, um den Kram
aus einer VM heraus über USB zum Laufen zu bekommen, werd ich dann noch
peu à peu hier abkippen.

Gruss,

Thomas

[1] Mal der WD Green (WDC WD40EZRX) bisserl auf den Zahn gefühlt:

root@cubietruck:~# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
Model Number: WDC WD40EZRX-00SPEB0
Serial Number: WD-WCC4E0210453
Firmware Revision: 80.00A80
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 7814037168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
device size with M = 1024*1024: 3815447 MBytes
device size with M = 1000*1000: 4000787 MBytes (4000 GB)
cache/buffer size = unknown
Nominal Media Rotation Rate: 5400
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, with device specific minimum
R/W multiple sector transfer: Max = 16 Current = 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
Power-Up In Standby feature set
* SET_FEATURES required to spinup after power up
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* 64-bit World wide name
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
* NCQ priority information
* unknown 76[15]
DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT LBA Segment Access (AC2)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
unknown 206[12] (vendor specific)
unknown 206[13] (vendor specific)
unknown 206[14] (vendor specific)
Security:
[...]

root@cubietruck:~# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 216 MB in 3.01 seconds = 71.69 MB/sec

root@cubietruck:~# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 288 MB in 3.00 seconds = 95.93 MB/sec

root@cubietruck:~# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 222 MB in 3.01 seconds = 73.71 MB/sec

root@cubietruck:~# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 300 MB in 3.01 seconds = 99.79 MB/sec

root@cubietruck:~# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 296 MB in 3.00 seconds = 98.56 MB/sec

root@cubietruck:~# hdparm --direct -t /dev/sda
/dev/sda:
Timing O_DIRECT disk reads: 438 MB in 3.00 seconds = 145.95 MB/sec

root@cubietruck:~# hdparm --direct -t /dev/sda
/dev/sda:
Timing O_DIRECT disk reads: 442 MB in 3.03 seconds = 145.93 MB/sec

root@cubietruck:~# hdparm --direct -t /dev/sda
/dev/sda:
Timing O_DIRECT disk reads: 438 MB in 3.03 seconds = 144.56 MB/sec

root@cubietruck:~# hdparm -M /dev/sda
/dev/sda:
acoustic = not supported

root@cubietruck:~# hdparm -W /dev/sda
/dev/sda:
write-caching = 1 (on)

[Thomas Kaiser]

Ingrid Kaiser schrieb am 25.11.2013 in <news:slrnl96t46.1so...@phg-online.de>
> frid...@gmail.com schrieb:

>> Anscheinend haben wohl schon Leute OMD auf irgendwelchen
>> Android-Tablets laufen lassen, die ja hardware-seitig nicht so weit
>> weg vom Cubie sind.
>
> Hmm... ich glaub, dass auch das Cubietruck im Vergleich zu gängigen
> Tablets eher untermotorisiert ist.

Grad mit der Basiskonfiguration der Allwinnder-SoCs beschäftigt und
erfolgreich das Cubie tiefergelegt und Breitreifen drangeschraubt :-)

Im Auslieferungszustand bzw. so wie zumindest das lubuntu-Basisimage des
Cubieteams voreingestellt ist, bootet die CPU mit 912 MHz, fährt dann
auf 720 MHz runter mit der Option, unter Last wieder auf 912 MHz
raufzutakten.

Das hab ich jetzt mal geändert und als Maximalfrequenz 1008 MHz erlaubt.
Als Ergebnis schnellt das Cubietruck im 7zip-bench von 845 [1] auf 925
hoch [2] (könnte mehr sein aber da spielt dann defintiv die Anbindung
bzw. clock speed des RAM mit rein). Unter Linux kann man diese Parameter
aber auch prima im laufenden Betrieb per /sys/devices/system/cpu/...
anpassen (siehe [3] und vgl. mit <http://linux-sunxi.org/Cpufreq>).

@Götz: Bitte entweder beim alten Wert die 0,9 GHz nachtragen oder mit
925 @ 1 GHz aktualisieren:

http://s1.hoffart.de/7zip-bench/?itm=45

Interessant auch noch: Die CPU reagiert auf Temperatur und taktet autom.
runter, wenn's ihr zu warm wird (hab zur Belustigung der Anwohner auch
kurz draußen gemessen. Da waren die Werte besser und vor allem deutlich
konstanter). D.h. die 925 @ 1 GHz sind "Bürowerte" (bei um die 20°) und
das bedeutet, dass im nächsten CucieCase das Board vertikal mit ebenso
vertikal ausgerichteten Kühlrippchenen am Kühlkörperchen verbaut wird.

Die Grundkonfiguration der Allwinner-SoCs findet in sog. fex-Dateien
statt. Als Beispiel die aktuell offizielle:

https://github.com/cubieboard/cubie_configs/blob/master/sysconfig/linux/cubietruck.fex

Die weicht von der mit lubuntu ausgelieferten nur insofern ab, als in
der "disp init configuration"-Sektion bei der lubuntu-FEX abweichend
"screen0_output_type = 3" statt "screen0_output_type = 4" drinsteht
(VGA vs. HDMI, alles schön im Filmchen in [4] gezeigt).

Ich hab mir jetzt die Maximal-CPU-Frequenz auf 1008 MHz hochgeschraubt,
aus dem Mini-USB-On-The-Go-Port einen normalen gemacht (und dabei das
Problem <https://groups.google.com/forum/#!topic/cubieboard/mhb55nTj7lo>
noch nebenbei behoben) und der NIC 'ne fixe MAC-Adresse zugewiesen (die
wird nämlich ansonsten bei jedem Neustart neu gewürfelt, was doof ist --
Lösungsvarianten siehe <https://github.com/cubieplayer/Cubian/issues/47>):

Vorher:

[usbc0]
usb_used = 1
usb_port_type = 2
usb_detect_type = 1

[dvfs_table]
max_freq = 912000000

Nachher:

[usbc0]
usb_used = 1
usb_port_type = 1
usb_detect_type = 0

[dvfs_table]
max_freq = 1008000000

[dynamic]
MAC = "020000eb8439"

Wie ändert man sowas: Auch relativ simpel: Auf dem cubie die erste
Partition des NAND-Flash bzw. der MicroSD-Card mounten, die dortige
script.bin-Datei ins fex-Format wandeln, editieren, wieder nach
script.bin wandeln, NAND-Flash _sicher_ schreiben, Reboot, fertig.

mkdir /mnt/nanda && mount /dev/nanda /mnt/nanda
bin2fex </mnt/nanda/script.bin >/tmp/script.fex
vi /tmp/script.fex
fex2bin </tmp/script.fex >/mnt/nanda/script.bin
sync && umount /mnt/nanda && reboot

Hinter bin2fex und fex2bin steckt das fexc-Binary, dessen Sourcen man
sich bei den Chinesen im Netz holen und problemlos kompilieren kann
(direkt auf dem cubie [4] -- bei lubuntu aber gar nicht nötig, da die
Tools bereits in /bin/ liegen -- oder auch am Mac -- so hab ich das eben
gemacht und mir die script.bin-Datei übers Netz vom cubie geholt [5]):

http://linux-sunxi.org/Sunxi-tools#bin2fex

Man holt sich die sunxi-tools von <http://linux-sunxi.org/FirstSteps>,
ruft zweimal "make" auf und hat die Tools zur Hand. Und was man da alles
grob einstellen kann, sieht man hier:

http://linux-sunxi.org/Fex_Guide

Immer schön Vorsicht walten lassen und im Zweifel Finger weg. Aber ich
werd mir da demnächst noch die Funktion der 4 LEDs auf dem Bord
umdefinieren (das Geblinke unterm Sofa nervt dann doch, wobei man das
reine Schalten auch unter Linux über /sys/class/leds/ bewerkstelligen
kann, bspw. "echo 0|255 > /sys/class/leds/green\:ph07\:led4/brightness",
siehe ebenfalls [4])

Gruss,

Ingrid, inzwischen Case-Modderin aus Leidenschaft... ;-)

[1] Vorher (max_freq = 912000000)

root@cubietruck:/tmp# 7zr b

7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,2 CPUs)

RAM size: 1825 MB, # CPU hardware threads: 2
RAM usage: 425 MB, # Benchmark threads: 2

Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 481 149 314 468 | 13091 197 601 1182
23: 501 153 335 510 | 12842 196 599 1175
24: 497 156 343 535 | 12747 198 598 1182
25: 469 153 349 535 | 12438 196 595 1169
----------------------------------------------------------------
Avr: 153 335 512 197 598 1177
Tot: 175 467 845

[2] Nachher (max_freq = 1008000000)

root@cubietruck:~# 7zr b

7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,2 CPUs)

RAM size: 1825 MB, # CPU hardware threads: 2
RAM usage: 425 MB, # Benchmark threads: 2

Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 492 148 324 479 | 14499 198 660 1309
23: 540 153 360 550 | 14143 197 658 1295
24: 533 156 367 573 | 14001 198 656 1299
25: 527 159 378 602 | 13743 198 653 1292
----------------------------------------------------------------
Avr: 154 357 551 198 657 1299
Tot: 176 507 925

Manuelle Anpassung der Frequenzen im laufenden Betrieb:

[3] root@cubietruck:~# echo "720000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
root@cubietruck:~# echo "720000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
root@cubietruck:~# 7zr b

7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,2 CPUs)

RAM size: 1825 MB, # CPU hardware threads: 2
RAM usage: 425 MB, # Benchmark threads: 2

Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 383 133 280 373 | 10497 197 480 947
23: 416 147 288 423 | 10165 194 480 930
24: 391 142 296 420 | 9861 191 479 915
25: 391 146 306 446 | 9929 195 478 933
----------------------------------------------------------------
Avr: 142 293 416 194 479 931
Tot: 168 386 674

[4] http://www.youtube.com/watch?v=4sn8uKvFIyU

[5] Bauen von fex2bin/bin2fex bzw. de facto fexc am Mac (natürlich Xcode
vorausgesetzt). Das Zeugs läßt sich auch problemlos verschieben,
siehe otool-Ausgabe:

macbookpro-tk:sunxi-tools tk$ make fex2bin
gcc -g -O0 -Wall -Wextra -std=c99 -D_POSIX_C_SOURCE=200112L -Iinclude/ -o fexc fexc.c script.c script_uboot.c script_bin.c script_fex.c
ln -s fexc fex2bin

macbookpro-tk:sunxi-tools tk$ make bin2fex
ln -s fexc bin2fex

macbookpro-tk:sunxi-tools tk$ file fexc
fexc: Mach-O 64-bit executable x86_64

macbookpro-tk:sunxi-tools tk$ otool -L /usr/local/bin/fexc
/usr/local/bin/fexc:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

[Goetz Hoffart]

Thomas Kaiser <Thomas...@phg-online.de> wrote:

> @G�tz: Bitte entweder beim alten Wert die 0,9 GHz nachtragen oder mit

> 925 @ 1 GHz aktualisieren:
>
> http://s1.hoffart.de/7zip-bench/?itm=45

Ich hab einfach beides gemacht. Und dabei f�llt mir auch wieder ein,
dass Tabellenzeilennummern zur (dauerhaften) Identifikation nicht
taugen, und ich besser eindeutige IDs vergeben sollte
<auftodolisteschreib>.

http://s1.hoffart.de/7zip-bench/?itm=45;46

Gr��e
G�t
--
http://www.knubbelmac.de/

[Thomas Kaiser]

Ingrid Kaiser schrieb in <news:slrnl98kaj.1um...@phg-online.de>

> Ich will's diesmal sauber angehen und arbeite mich mal von unten nach
> oben vor. D.h. zuallererstmal lokal die Grenzen der Platte (und deren
> auf dem Cubie zur Verfügung stehenden Features ausloten [1]), dann
> vergleichen mit bekanntermaßen sauber funktionierender Hardware (bei mir
> ein Shuttle SX58J3) und herausfinden, an welcher Stelle es klemmt. Und
> wo vorhanden, Lösungen finden/dokumentieren. Die verbaute Platte sollte
> theoretisch schneller als GBit-ENet sein, dito das im Cubietruck
> verbaute SATA-Interface (da haben Leute mit 'ner SSD sowohl lesend als
> auch schreibend deutlich über 100 MB/sec gemessen)

Um gscheid messen zu können und weil's iozone als fertiges Paket nicht
für ARM gab (oder ich's nicht gefunden habe -- jetzt auch wurscht), hab
ich mir erstmal ein iozone-deb gebacken [1].

Dann drüber gestolpert, dass das Partitions-Alignment wohl doof, d.h.
unperformant ist. Geändert (siehe [2]), hat aber nur 1-2 MByte/sek mehr
gebracht. Die Schreib-Performance ist nach wie vor bescheidenst: Nur um
die 40 MByte/sek (siehe [3]). "smartctl --all /dev/sda" bescheinigt
keine Probleme. Also Platte mal an "Referenzsystem" probieren:

http://kaiser-edv.de/tmp/9nQgUX/shuttle-front.jpg
http://kaiser-edv.de/tmp/9nQgUX/shuttle-back.jpg
(das Shuttle ist für sowas prima geeignet, weil's hinten raus noch
SATA-Strom führt und mit passendem Kabel daherkommt)

Und auf dem Shuttle sind sie Werte _normal_ für so 'ne lahme Platte: ca.
135 MByte/sek schreibend und ca. 145 MByte/sek lesend [4].

Jetzt bin ich noch dem Thread hier nachgegangen, der einen Einfluß der
dynamischen CPU-Herauf-/Heruntertaktung annimmt:

https://groups.google.com/forum/#!msg/cubieboard/RNYotebbofc/IyE2jh9Zd7MJ

Aber

echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance >/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

helfen auch nicht wirklich. Naja, mal bei den Cubie-Leuten direkt
nachfragen...

Gruss,

Thomas

[1] Das frisch gebackende iozone-deb findet sich hier:
http://kaiser-edv.de/downloads/iozone3_397-2ubuntu1_armhf.deb

Package: iozone3
Priority: optional
Section: non-free/utils
Installed-Size: 618
Maintainer: Steve M. Robbins <s...@debian.org>
Architecture: armhf
Version: 397-2ubuntu1
Depends: libc6 (>= 2.15-0ubuntu8), libgcc1 (>= 1:4.4.0)
Size: 433582
Description: Filesystem and Disk Benchmarking Tool
Iozone is useful for determining a broad benchmark of filesystem
performance. The benchmark tests file I/O performance for the
following operations: Read, write, re-read, re-write, read backwards,
read strided, fread, fwrite, random read/write, pread/pwrite variants.
Homepage: http://www.iozone.org/

[2] Partitions-Alignment korrigieren (Details siehe bspw.
<http://www.thomas-krenn.com/de/wiki/Partition_Alignment>)

root@cubietruck:/# parted -a optimal /dev/sda
GNU Parted 2.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) mktable gpt
Warning: The existing disk label on /dev/sda will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Yes

(parted) mkpart primary 0% 100%

(parted) p
Model: ATA WDC WD40EZRX-00S (scsi)
Disk /dev/sda: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 4001GB 4001GB primary

(parted) unit s

(parted) p
Model: ATA WDC WD40EZRX-00S (scsi)
Disk /dev/sda: 7814037168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 2048s 7814035455s 7814033408s primary

[3] WD Green an cubie ("cd /data && iozone -a -g 1000m -s 1000m -i 0 -i 1 -r 32K")

Iozone: Performance Test of File I/O
Version $Revision: 3.397 $
Compiled for 32 bit mode.
Build: linux

Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer.
Ben England.

Run began: Tue Nov 26 18:12:46 2013

Auto Mode
Using maximum file size of 1024000 kilobytes.
File size set to 1024000 KB
Record Size 32 KB
Command line used: iozone -a -g 1000m -s 1000m -i 0 -i 1 -r 32K
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.

KB reclen write rewrite read reread
1024000 4 40129 41193 364811 482399
1024000 32 39501 40906 364643 431036
1024000 512 39831 40748 382392 374300
1024000 16384 39485 40115 325406 413805

[4] WD Green an Shuttle:

1024000 4 153442 154356 5086227 5170569
1024000 32 151381 152915 6218949 6296544
1024000 512 146854 150564 5472131 5521526
1024000 16384 153385 155938 3803941 3815340

Und zur Sicherheit auch nochmal eine Messung mit 48 GByte
Dateigröße (3 x RAM) um Cache-Effekte auszuschließen:

49152000 16384 133803 137019 145757 145899

[Thomas Kaiser]

Thomas Kaiser schrieb am 25.11.2013 in <news:slrnl96t46.1so...@phg-online.de>

> frid...@gmail.com schrieb in <news:0426c4a2-c18b-49e5...@googlegroups.com>
>> Anscheinend haben wohl schon Leute OMD auf irgendwelchen Android-
>> Tablets laufen lassen, die ja hardware-seitig nicht so weit weg vom
>> Cubie sind.
>
> Hmm... ich glaub, dass auch das Cubietruck im Vergleich zu gängigen
> Tablets eher untermotorisiert ist. Eine interessante Alternative
> könnte noch das Nitrogen6x sein (Quad-Core A9, ebenfalls SATA, GBit-
> Ethernet):)
>
> http://www.module-store.com/de/Evaluation-Boards/freescale-i.MX6-Quad-Core/Nitrogen6x-freescale-i.MX6-Quad-low-cost-Entwicklungsboard
>
> Aber nur halb so viel RAM und mehr als doppelt so teuer (dafür kann's
> gleich PoE).

So, ich hab mir jetzt noch das Wandboard Quad angetan (und nach den dort
gewonnenen Erfahrungen werd ich brav die Finger vom technisch sehr
ähnlichen Nitrogen6x lassen, da das die selbe NIC-Krankheit hat wie das
Wandboard):

http://www.wandboard.org/index.php/details
http://www.denx-cs.de/shop/?q=WandboardQuad

Um's kurz zu machen:

Pro:

- SATA-Performance: ca. 85/100 MByte/sek (schreibend/lesend)
- mehr Wumms Dank Quad-Core-A9 (7-zip/armel kommt auf über 2000 Zähler)
- wer WLAN nutzen wollte, kann hier 'ne gscheide externe Antenne
anschließen
- Total schicker Kühlkörper und zweilagiges EDM-Design (Bilder eines
Clusterchens hier: http://blog.bigboards.io/post/60764495527/)

Contra:

- NIC-Performance grottig (RX errors wie Hölle ohne Gegenmaßnahmen)
- Stromversorgung für 3,5"-Platte Bastelei oder mittels zus. Netzteil
- Linux-Situation durchwachsen (die "schlüsselfertigen Lösungen" sind
entweder nicht auf der Höhe der Zeit oder es fehlen ihnen Features
wie Support für 3D-/Videodekodierung auf der GPU)

Wer sich damit spielen will: Es gibt ein frisches Yocto-Image, das
eigentlich vielversprechend ist (weil armhf-basierend und wesentliche
Onboard-Komponenten unterstützend):

http://forums.wandboard.org/viewtopic.php?f=10

Aber da hat man dann am Ende wirklich ein äußerst nackiges Linux unter
den Fingern ohne Paketmanagement und dergleichen. Es kann zwar rpm aber
damit muß man sich dann 'ne Compiler-Toolchain zu Fuß bauen, etc. -- aus
dem Alter bin ich eigentlich raus.

Anbei für die, die das Ding ggf. interessiert, noch eine Anleitung, wie
man mit der schlüsselfertigsten Variante in Kombination mit Mac simpel
zurechtkommt:

Ubuntu (Ubuntu 12.04.2 armel) Image laden und entpacken:

http://www.wandboard.org/index.php/downloads

bzw.

http://www.wandboard.org/images/downloads/ubuntu-12.04.2-gpu4.1.0-20131122-img.xz

Micro-SD-Card in Adapter stecken, Adapter in Mac, falls SD-Card
gemountet werden sollte im Festplatten-Dienstprogramm die Partition
_deaktivieren_ (nicht "auswerfen") und dann in der Shell als root "dd
if=/pad/zu/ubuntu-12.04.2-gpu4.1.0-20131122-img of=/dev/$diskX bs=1m"
("/pad/zu/" und "diskX" passend ersetzen -- wegen Letzterem hilft der
Aufruf von "diskutil list")

Weiter nach Anleitung (partiell falsch, was bspw. den SATA-Anschluß
angeht -- der funktioniert beim Quad)

http://www.wandboard.org/images/downloads/wbquad-revb1-userguide.pdf

Micro-SD-Card in den Slot auf dem EDM-Board stecken (das Wandboard hat
zwei SD-Slots!), LAN, HDMI und USB-Tastatur dran, PoE-Splitter auf 5V
stellen (bzw. 5V/2A-Stromquelle anschließen) und Wandboard unter Strom
setzen. Es bootet ein komplettes Ubuntu inkl. Desktop (in die Shell
gelangt man per [ctrl]-[alt]-[f2]). Login wieder mal "linaro/linaro",
allerdings läuft kein sshd, d.h. das Ding ist von außen erstmal nicht
vernünftig erreichbar.

(und noch zwei Nachteile: Von den 2 GByte sind mit diesem Kernel nur 1,8
nutzbar. Außerdem läuft aus welchem Grund auch immer der bluetoothd Amok
bis man ihn per "sudo service bluetooth stop" ausknipst -- nach jedem
Neustart, d.h. idealerweise irgendwie per Startskript oder Analyse des
Fehlers)

Die erste "apt-get update/upgrade"-Orgie zieht sich halbe Ewigkeiten
(SD-Card ist eben kein D-Zug). Anschl. hat man dann ein "Ubuntu 12.04.3
LTS (GNU/Linux 3.0.101+ armv7l" und ein "apt-get install openssh-server"
später kommt man endlich vernünftig auf das Ding. Und ein "apt-get
install cpufrequtils" später kann man auch auf Leistung- vs. -aufnahme
Einfluß nehmen (/sys/devices/system/cpu/). Per default taktet sich das
Ding zwischen 996000 max., 792000 normal und 396000 min. je nach Last
hin und her (in Mhz natürlich), solange der "scaling_governor" auf
"ondemand" steht und nicht fix. Maximal- oder Minimalleistung diktiert
ist.

Für das cubietruck hab ich mir ja schon ein iozone-deb für armhf gebaut,
für das Wandboard braucht's leider armel (wirklich ärgerlich, dass fürs
Wandboard "schlüsselfertig" nur armel geliefert wird -- warum ist bspw.
hier <http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/>
beschrieben inkl. Konsequenzen). iozone-Details unter [1]

Netatalk 3.1 zu bauen war gemäß [2] ein Kinderspiel (ich hab das auch
mit dem in 3.1 neuen Spotlight-Support probiert -- da gibt's unter armel
aber noch einen Kompilierfehler. Wenn das gefixt ist, poste ich nochmal
ein Followup). Und damit funktioniert das Ding natürlich problemlos als
TimeMachine-Server (mit den üblichen Einschränkungen bzgl. "TM durchs
Netz" -- an der Stelle ebenfalls nervig: Der Wandboard-Kernel hat
keinen Support für btrfs, was unter Gesichten der Snapshot-Erstellung
blöd ist [3]).

Einfach eine Share mit "time machine = yes", die Publikation der nötigen
Bonjour-Records machen Netatalk/Avahi, und man kann die Share sowohl bei
Backup als auch im Desaster Recovery Fall einfach so auswählen. Aber das
Sichern ist extrem lahm wegen den Problemen mit dem verbauten Atheros-
AR8031-NIC. Einen Eindruck DAVN bekommt man bei der "Konkurrenz", die
BOARDS mit der selben Kombination CPU/NIC bauen:

http://boundarydevices.com/i-mx6-ethernet/

Solange das nicht gelöst ist (so es denn überhaupt gelöst werden kann),
bleibt das cubietruck erstmal mein Favorit -- trotz dortigem viel
niedrigeren SATA-Durchsatz. Nächste Schritte mit dem Wandboard sind
dann, die armhf-Varianten auszuprobieren (weitere µSD-Cards sind
bestellt :-)

http://www.armhf.com/index.php/boards/wandboard/
http://eewiki.net/display/linuxonarm/Wandboard

Sollte mir der Spieltrieb bleiben, wären die nächsten Versuche eher
wieder lowend, d.h. MeLE-basiert:

http://www.aliexpress.com/item/shipping-free-mele-a2000-Andrews-network-HD-hard-disk-player-mini-saloon-computer-TV-box-Allwinner/575035430.html
http://dx.com/p/mele-a1000g-2gb-ram-16gb-rom-quad-core-android-4-1-network-tv-player-black-225850

Aus der alten Version hat ein Franzose einen Cluster gebaut (unter dem
Link gleich oben Weiterführendes zu "professionellem" ARM-Geclustere):

http://guillaumeplayground.net/allwinner-a10-cluster-mele-a2000/

Und der potentere Nachfolger kommt für unter 80,-€ mit Quad-Core, 2
GByte RAM und SATA... und eben nur Fast-Ethernet, was die Erwartungen
schön niedrig hält. Sollte die Frustrationstoleranz dann wieder ein
wenig ins Positive tendieren, dann rück ich ggf. dem Utilite Pro
<http://heise.de/-1917940> mit 1,2 Ghz Quad-Core-i.MX6, 2 GByte RAM,
mSATA-Port und zus. Intel I211 Gbit-NIC auf die Pelle:

http://ark.intel.com/de/products/64404/Intel-Ethernet-Controller-I211-AT

(hoffentlich liefert das Intel-typischen LAN-Durchsatz an PCIe)

Wenn damit vernünftige LAN-Durchsatzraten auf ARM zu erzielen sind und
mSATA-zu-SATA-Adapter <http://www.hwtools.net/Adapter/PMMD.html> nicht
wieder mit anderen Nachteilen (wie bspw. grottige Performance ;-)
einhergehen, dann könnte das evtl. die Basis für so'n NAS sein, wie es
mir vorschwebt: energieeffizient, hochgradig flexibel, große Kapazität
und von den Komponenten her (also CPU, SATA-Port und NIC) so
ausbalanciert, dass der Einsatz als NAS endlich mal rund wird. Die
inneren Werte lesen sich jedenfalls mal nicht allzu schlecht:

http://utilite-computer.com/web/utilite-pro-specifications

Aber mal abwarten...

Gruss,

Thomas

[1] iozone 3.397 gebaut gemäß http://wiki.ubuntuusers.de/pBuilder aber
anstelle "apt-get source ..." die drei Files von hier per wget
http://packages.ubuntu.com/de/source/quantal/iozone3 runterladen und
dann weiter. Fertiges Paketchen hab ich mal wieder online gestellt:
http://kaiser-edv.de/downloads/iozone3_397-2ubuntu1_armel.deb

[2] http://netatalk.sourceforge.net/wiki/index.php/Install_Netatalk_3.0.6_on_Debian_7_Wheezy

[3] btrfs macht das Hantieren mit mehreren Snapshots leichter (und
unterstützt Features wie LZO-Kompression, die auf einem Quadcore-
ARM als TM-Ziel oder "general purpose NAS" grad noch sinnvoll sein
könnten). Snapshots sind immer dann eine tolle Sache, wenn ein TM-
Sparsebundle bei der Sicherung übers Netz mal wieder einen an der
Klatsche hat. Aber eben im Wandboard-default-Kernel kein BTRFS-
Support :-(

Ach ja: Und unter Ubuntu (zumindest 12.04) gibt's noch einen Bug
bzgl. der btrfs-userland-Tools, die einen fsck verhindern, siehe
https://bugs.launchpad.net/ubuntu/+source/btrfs-tools/+bug/748340

Da hülfe dann das Nutzen des entsprechenden Debian-Pakets. Da die
Anleitung dort oben bisschen oll ist und die Download-Links
inzwischen andere, anbei noch das Vorgehen abgekippt:

cd /tmp
apt-get build-dep btrfs-tools
apt-get install libblkid-dev liblzo2-dev
wget http://ftp.de.debian.org/debian/pool/main/b/btrfs-tools/btrfs-tools_0.19+20130705.orig.tar.xz
wget http://ftp.de.debian.org/debian/pool/main/b/btrfs-tools/btrfs-tools_0.19+20130705-3.debian.tar.xz
wget http://ftp.de.debian.org/debian/pool/main/b/btrfs-tools/btrfs-tools_0.19+20130705-3.dsc
dpkg-source -x btrfs-tools_0.19+20130705-3.dsc
cd btrfs-tools-0.19+20130705/
dpkg-buildpackage -rfakeroot
dpkg -i ../btrfs-tools_0.19+20130705-3*.deb

Funktioniert klaglos unter sowohl armel als auch x86_64 (jeweils 12.04)

[Thomas Kaiser]

Ingrid Kaiser schrieb in <news:slrnl9ova1.8qd...@phg-online.de>

> Netatalk 3.1 zu bauen war gemäß [2] ein Kinderspiel (ich hab das auch
> mit dem in 3.1 neuen Spotlight-Support probiert -- da gibt's unter
> armel aber noch einen Kompilierfehler.

Der Fehler hat 'nen Namen: Ingrid -- ich war zu doof, nach fehlerhaftem
configure-Aufruf im ersten Versuch wieder saubere Randbedingungen im
zweiten zu schaffen. Der wie gewohnt exzellente NetAFP-Support hat mich
dankenswerterweise mit der Nase draufgestubst... und anschl. lief alles
klaglos durch. Wer Netatalk 3.1 (*inkl. Spotlight-Suche in Dateien*)
unter Debian/Ubuntu einsetzen will und die Variante "Spaziergang"
bevorzugt, hält sich am Besten an diese vorhin aktualisierte Anleitung:

http://netatalk.sourceforge.net/wiki/index.php/Install_Netatalk_3.1.0_on_Ubuntu_12-13_(or_Debian_Wheezy)

Getestet unter 12.04 LTS auf x86_64/armel/armhf.

Gruss,

Thomas

[Thomas Kaiser]

Gerald E:scher schrieb am 25.11.2013 in <news:20131125232536....@ID-37099.user.uni-berlin.de>

> Thomas Kaiser schrieb am 23/11/2013 22:52:
>

>> Darf ich vorstellen: ein Gbit-fähiges Multiprotokoll-Multimedia-NAS

>> (inkl. zigtrialliarden möglichen Add-Ons) mit 4 TByte HD, Anschlüssen

>> wie Sau [1], kaum Leistungsaufnahme, per PoE [2] befeuerbar, in zeit-

>> losem MDF-/Kabelbinder-Chassis und natürlich lüfterlos/lauwarm für ca.

>> 270,- € brutto [3]. Mehr als die Hälfte der Kosten verschlingt leider

>> die Verbauung einer bzw. eben der 3,5"-HD:
>
> Nett.
>
>> [7] Ich hab mal mit Netatalk 3.1 getestet.
>
> Bitte einen Bericht, wie das Kistchen als TM-Server performt.

Ich schließ das Thema vorerst mal ab und liefer ein Zwischenergebnis
bzgl. Tauglichkeit als TimeMachine-Ziel. Das Wandboard, das zwar mehr
Wumms hat (mehr als doppelt so schnelle CPU [1], SATA-Durchsatz deutlich
ausgewogener -- 90/100 MByte/sec schreibend/lesend) disqualifiziert sich
ohne häßliches bzw. aufwändiges Feintuning im Netzwerk:

http://kaiser-edv.de/tmp/9nQgUX/default-net-performance.png

(Wandboard Quad, cpu_governor auf performance, Netatalk 3.1, Ubuntu
12.04 armel, kein handgedrechselter Kernel und Boot-Optionen und daher
unterirdische LAN-Performance gerade bzgl. RX -- Erklärung hier im
Thread bzgl. der iMX6-Boards von Boundary Devices bereits abgeliefert.
Die Seagate am Wandboard ist ca. Faktor 1,5 _schneller_ als die WD Green
im "CubieNAS").

Ganz anderes Bild am Cubietruck (sobald ich mal richtig gemessen habe
-- die alten Messungen waren aus VMs auf 'nem Mac Mini heraus, wo's
dann irgendwo im LAN hakt):

http://kaiser-edv.de/tmp/9nQgUX/ext4-netatalk-3.1-no-tuning.png

(Cubietruck, cpu_governor auf ondemand, Netatalk 3.1, Ubuntu 12.04
armhf, WD Green, Modifikation der .fex-Datei wie im Thread beschrieben,
um das Grundload-Problem zu beheben. Identische ext4-Mount-Optionen wie
beim Wandboard: "noatime,data=writeback". Aber das sollte an der Stelle
null Unterschied machen)

Das cubietruck bzw. generell A10/A20-Devices unter Linux scheinen ein
sehr unausgewogenes Lese-/Schreibverhältnis am SATA-Port aufzuweisen:

https://groups.google.com/forum/m/?fromgroups#!category-topic/cubieboard/tD0AxHx5Ync

Ich hab Guillaume, den MeLE-Guru, der aus zig dieser MeLE-Settop-Boxen
Cluster baut, auch mal um akkurate Messungen gebeten. Und hier noch wen
gefunden, der _richtig_ gemessen hat und ebenfalls bei knapp über 40
MByte/sec schreibend stehenbleibt.

https://groups.google.com/forum/#!msg/linux-sunxi/fZbKdS9m6bc/-57nxQUrsJwJ

(die stille Hoffnung ist nach wie vor, die Leute, die sich mit SATA rund
um A10/A20 auskennen, zu 'ner Prüfung zu bewegen, ob das nicht einfach
was im Treiber sein kann und keine Limitation der Allwinner-SoCs per se:
"Huch, wenn man aus der 0 da ne 1 macht, löppt das doppelt so schnell")

Ach ja, noch ein kleiner Vorteil des cubietruck, wenn man damit
liebäugelt, eine 3,5"-HD anzuschließen: Mit dem kleinen Spannungswandler-
Bord und deren Spezialkabel, die ebenfalls von cubietech stammen, gibt
es eine meines Erachtens elegante Lösung, mit nur einer 12V-Quelle Board
und Platte zu versorgen (hier eben per PoE :-)

Nun zu Netatalk (das Folgende trifft prinzipiell für jedes aktuelle
Ubuntu oder auch Debian zu -- bei dem Linux-Image von cubietech brauchte
es allerdings noch einmal ein "apt-get install avahi-daemon", damit nach
Installation/Konfiguration von Netatalk die Linux-Kiste automagisch als
TM-Ziel im Netz auftaucht). Der komplette Vorgang inkl. der relevanten
Parameter -- TM an und Begrenzung der Volumegröße, damit sich mehrere zu
sichernde Kisten auch ohne fixe Partitionierung nicht in die Quere
kommen -- für die afp.conf steht hier beschrieben:

http://netatalk.sourceforge.net/wiki/index.php/Install_Netatalk_3.1.0_on_Ubuntu_12-13_(or_Debian_Wheezy)

Mehr ist es in der Tat nicht. Ich hab gestern mal eine Kiste über GBit-
ENet wegsichern lassen. Für ca. 106 GByte über 3,5 Stunden. Das ist auf
den ersten Blick schlecht. Allerdings sichert die Kiste vom Bauchgefühl
her genauso lahm auf USB-Platte. Muß ich mir nochmal anschauen aber
definitiv nicht jetzt (schon zu viel Lebenszeit in den Kram versenkt).

Das cubietruck steckte im Monitoring. Der spannende Zeitraum ist der
zwischen 23:45 und ca. 3:15-3:30:

http://kaiser-edv.de/tmp/9nQgUX/OpenNMS-Report.pdf

Load kaum über 1.5, komplettes RAM automatisch als FS-Cache alloziiert,
CPU ab und an über 40%, LAN-Durchsatz lahme 10 bis max. 15 MByte/sek.
Auf dem Client extrem entspanntes Bild [2]. Die viel spannendere iostat-
Ausgabe auf dem cubietruck hab ich dummerweise entsorgt. Allerdings weiß
ich aus dem Gedächtnis noch, dass da konstant %iowait-Werte von 5%-10%
gelistet wurden. An der Stelle müsste "man" mal vergleichen mit potenten
Netatalk-TM-Lösungen (steht auf der TODO aber aktuell null Zeit für den
Spaß)

Ach ja, zur Handhabung noch: Nach Installation/Konfiguration von
Netatalk wie im Netatalk-Wiki beschrieben, publiziert Netatalk ohne
weitere Konfiguration die TM-Fähigkeit per Bonjour. Es reicht dann, in
den Systemeinstellungen die entsprechende TM-AFP-Share auszuwählen,
einmal Benutzername/Paßwort für die Share einzugeben und fertig (Stand
10.8.5 hier auf den Clients). Wenn ein Backup ansteht, mountet sich das
System automatisch die AFP-Share her (sollte die Share parallel schon
gemountet sein, dann doppelt und unter eindeutigem Mountpoint, siehe
nachfolgende "df -h"-Ausgabe), mountet das daraufliegende SparseBundle
bzw. legt eines an, wenn noch nicht existent, und sichert in das
SparseBundle rein.

//lin...@cubietruck.local/WD%20Green%20on%20cubietruck 3.4Ti 4.0Gi 3.4Ti 1% 1061398 911528094 0% /Volumes/WD Green on cubietruck-1
/dev/disk3s2 3.4Ti 3.9Gi 3.4Ti 1% 515214 455737542 0% /Volumes/Time Machine-Backups

Das Ganze überlebt stundenlangen Ruhezustand mitten im Backup, solange
sich das zu sichernde Device beim Aufwachen _rasch genug_ wieder mit dem
AFP-Server verbinden kann (wenn ich's richtig beobachtet habe, dann
überlebt das sogar einen Wechsel des Interfaces -- Deckel zu, LAN
abgestöpselt, Stunde später wieder aufgeweckt und Backup lief per WLAN
weiter. Bin mir aber nicht mehr 100% sicher). Wenn nicht, droht halt das
übliche zerschossene SparseBundle. Um das abzufedern wäre eine sinnvolle
Snapshot-Verwaltung auf dem CubieNAS toll. Leider haben auch die cubies
dem Kernel in ihrem Linaro-Image keinen btrfs-Support spendiert (das
kann Snapshots mit weniger Nebenwirkungen als bspw. ext4 und könnte mit
compression=lzo in der Kombination "CPU hat noch Luft" und "SATA writes
zu lahm" evtl. sogar deutlich punkten. Bleibt auch noch anzutesten --
aber eben nicht jetzt. Keine Zeit für den Quatsch.

Ich krieg jetzt in paar Wochen ein MeLE A2000G und den USB-Gbit-NIC
hier:

https://groups.google.com/forum/m/?fromgroups#!category-topic/cubieboard/3-XvhQvddQI

(für zusammen 70,-€ -- wollte eigentlich den Vorgänger A2000, der war
aber nicht mehr lieferbar und der chinesische Händler schickt jetzt
lieber den Nachfolger als sich das Gschiß mit Kostenrückerstattung
anzutun). Die MeLE-Dinger sind technisch sehr nah an den Cubieboards,
haben halt keine GPIO-Pins und sowas, dafür ein Gehäuse, Netzteil, SATA-
Tochterboard mit zumindest Stromversorgung für 2,5"-Platten ab Werk. Und
mit dem USB-Nöpsel dran evtl. ausreichende Performance für so lowend-
Backup-/NAS-Geschichten. Man wird sehen bzw. ich werd testen (irgendwann
dann)

Was man ja im Eifer der Messungen nie vergessen sollte, ist, dass ARM
nicht Performance sondern Effizienz bedeutet. Das CubieNAS mit laufender
4 TByte-Platte schluckt einen Bruchteil dessen, was 'ne Desktop-CPU
bereits idle verbraten würde.

Gruss,

Thomas

[1] 7-zip-Benchmarks des Wandboard Quad: http://nixdev.com/?p=365
@Götz, ich hatte Dir ja schon das "Kleingedruckte" geschickt... und
denke, dass eine halbwegs exakte Einstufung des Wandboard Quad bei
ca. 2000-2100 @ 1 GHz liegen dürfte, da 7-zip rein Integer-basiert
ist und sich demnach armel/armhf bzw. Soft- vs. Hard-Float nicht
auswirken sollten, siehe
https://wiki.linaro.org/OfficeofCTO/HardFloat/Benchmarks201205

[2] iostat-Mitschnitt alle Minute, disk0 ist die lokale Platte, disk3
ist das TM-Sparsebundle, das vom Mac automatisch auf der
AFP-Freigabe erzeugt wurde:

bash-3.2# iostat 60
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
19.33 19 0.35 112.20 0 0.00 3 3 94 2.44 2.10 1.89
52.11 225 11.47 56.05 194 10.63 10 11 79 3.29 2.30 1.97
53.72 221 11.58 58.02 196 11.11 10 11 79 2.86 2.35 2.01
51.68 267 13.50 79.96 161 12.61 10 11 79 2.77 2.43 2.06
75.29 179 13.17 100.14 107 10.45 5 8 87 1.98 2.28 2.03
27.29 163 4.36 49.05 149 7.11 5 8 87 2.29 2.35 2.07
61.76 203 12.24 97.32 115 10.88 5 8 86 2.57 2.42 2.12
65.05 179 11.37 84.01 135 11.10 6 8 86 3.42 2.62 2.20
48.29 289 13.63 120.65 97 11.48 6 8 86 2.75 2.56 2.21
28.49 249 6.93 30.37 240 7.13 6 9 85 2.72 2.56 2.23
27.84 356 9.69 28.48 329 9.15 7 9 84 2.54 2.55 2.25
101.65 149 14.79 119.07 125 14.55 5 8 87 2.49 2.51 2.25
24.80 361 8.74 29.67 261 7.56 9 10 81 1.88 2.33 2.20
34.17 339 11.30 51.00 211 10.48 5 8 87 1.96 2.25 2.17
194.63 79 15.00 280.83 56 15.29 4 7 89 2.01 2.24 2.17
121.96 139 16.60 161.28 91 14.31 4 7 89 2.02 2.20 2.16
153.88 88 13.24 203.50 68 13.42 4 7 89 1.49 2.04 2.10
87.13 166 14.16 181.84 76 13.57 6 7 87 2.92 2.35 2.21
44.71 320 13.95 144.29 77 10.85 6 8 86 2.58 2.35 2.22
110.05 121 12.97 210.65 67 13.86 6 8 86 2.02 2.28 2.21
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
59.93 238 13.90 79.87 163 12.74 6 8 86 1.63 2.11 2.15
57.52 193 10.86 73.40 149 10.66 6 8 87 1.99 2.17 2.16
111.40 134 14.54 139.91 100 13.62 4 7 90 2.16 2.15 2.15
33.81 290 9.59 45.21 190 8.39 7 10 84 2.15 2.12 2.14
71.46 169 11.79 85.64 141 11.81 4 8 88 2.42 2.23 2.18
28.52 293 8.17 29.81 258 7.50 6 8 85 3.17 2.45 2.26
30.33 361 10.68 31.75 296 9.19 7 9 84 3.42 2.60 2.33
34.54 278 9.37 42.08 203 8.35 7 9 83 3.29 2.77 2.41
74.27 240 17.41 277.55 57 15.40 5 8 87 2.50 2.65 2.39
59.25 207 11.98 93.90 117 10.70 5 8 86 2.29 2.55 2.36
82.93 146 11.82 103.74 105 10.60 5 7 88 2.48 2.52 2.36
36.81 262 9.41 39.35 228 8.77 6 9 85 2.49 2.52 2.37
45.12 265 11.69 44.92 230 10.11 4 8 88 1.80 2.35 2.31
82.04 156 12.46 193.88 69 13.15 4 8 88 2.08 2.30 2.30
65.52 170 10.87 90.38 130 11.50 5 8 87 1.86 2.21 2.26
96.34 126 11.83 105.81 117 12.10 3 7 90 2.61 2.32 2.29
54.65 212 11.30 58.64 190 10.88 4 7 88 2.23 2.26 2.27
11.63 555 6.31 12.30 565 6.79 7 11 82 2.09 2.21 2.25
28.31 441 12.18 37.54 279 10.22 7 10 83 2.16 2.22 2.25
25.85 359 9.07 25.05 349 8.54 6 9 85 1.89 2.10 2.20
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
89.72 148 12.93 116.93 105 11.96 6 7 87 1.30 1.91 2.12
43.68 259 11.05 46.54 225 10.23 5 7 88 1.50 1.87 2.09
36.83 265 9.54 45.14 190 8.38 6 8 86 1.62 1.85 2.07
29.28 387 11.07 34.66 284 9.61 6 9 84 2.18 1.99 2.10
35.02 288 9.84 48.13 227 10.69 5 8 88 2.29 2.04 2.11
17.26 487 8.20 16.92 481 7.95 7 10 84 2.33 2.11 2.13
39.84 340 13.23 54.33 230 12.23 5 8 87 1.41 1.88 2.04
38.58 268 10.09 36.80 266 9.57 5 8 87 2.25 2.08 2.10
18.72 524 9.59 20.00 445 8.70 8 10 83 2.86 2.29 2.18
38.87 383 14.54 37.53 345 12.66 6 10 84 2.54 2.32 2.19
21.46 374 7.84 24.47 316 7.55 7 10 84 3.03 2.50 2.27
29.11 323 9.18 29.11 315 8.97 6 9 85 2.57 2.45 2.26
30.77 276 8.30 31.13 258 7.86 6 8 86 2.57 2.46 2.28
41.70 275 11.18 49.32 212 10.21 5 8 87 1.78 2.27 2.21
41.20 215 8.67 72.89 122 8.65 9 9 82 2.22 2.32 2.24
30.48 241 7.17 29.95 226 6.61 6 8 86 1.82 2.18 2.19
81.90 220 17.63 173.10 89 14.99 3 7 90 2.15 2.22 2.20
45.42 209 9.29 64.73 151 9.55 5 8 87 2.01 2.22 2.21
29.93 204 5.95 39.38 162 6.22 8 11 82 1.70 2.09 2.16
97.84 127 12.11 145.33 86 12.27 4 8 88 1.49 1.95 2.10
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
77.31 125 9.46 83.54 108 8.81 5 8 87 1.57 1.89 2.06
56.98 209 11.65 73.85 156 11.22 6 9 85 2.06 1.96 2.08
12.05 268 3.15 14.82 265 3.84 5 9 86 2.58 2.05 2.10
18.99 214 3.97 11.51 893 10.04 4 8 88 2.14 2.03 2.08
43.06 371 15.58 62.98 187 11.53 7 9 85 1.79 1.96 2.05
63.79 200 12.44 498.66 24 11.91 4 6 89 1.60 1.85 2.00
79.99 127 9.93 155.47 67 10.20 9 8 83 2.35 2.06 2.07
58.83 116 6.66 15.93 814 12.67 6 8 86 2.03 2.07 2.07
81.88 183 14.66 181.97 74 13.22 21 9 71 2.67 2.28 2.16
26.51 209 5.42 47.85 166 7.76 13 11 76 4.49 2.77 2.34
21.95 317 6.80 22.84 285 6.35 17 15 68 3.18 2.67 2.33
15.46 388 5.85 17.63 425 7.31 20 19 61 3.18 2.74 2.37
31.98 291 9.08 47.55 206 9.57 13 12 74 2.80 2.83 2.44
89.11 200 17.41 206.58 75 15.20 7 9 85 2.81 2.87 2.48
73.39 118 8.43 123.31 91 11.00 7 8 86 2.99 2.89 2.51
84.20 99 8.18 113.52 86 9.49 8 8 84 2.50 2.77 2.49
52.31 192 9.81 58.42 158 9.01 9 9 83 2.15 2.61 2.45
56.48 253 13.97 53.11 218 11.30 5 8 87 2.13 2.50 2.41
36.16 222 7.84 70.02 128 8.78 6 8 86 2.36 2.53 2.43
101.87 167 16.58 182.98 87 15.63 4 7 88 2.40 2.50 2.42
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
76.46 124 9.28 114.60 78 8.71 5 6 89 1.90 2.35 2.37
47.11 396 18.21 429.78 31 13.03 4 8 88 1.85 2.27 2.34
41.91 169 6.93 72.01 84 5.93 7 7 86 3.10 2.48 2.41
53.11 173 8.97 71.43 119 8.33 6 8 86 2.32 2.40 2.38
32.35 212 6.70 43.65 139 5.93 8 10 83 1.59 2.21 2.31
33.55 232 7.61 33.41 208 6.78 6 8 86 2.31 2.33 2.35
31.70 278 8.61 32.51 226 7.17 7 9 84 3.11 2.50 2.41
14.13 536 7.40 20.39 239 4.75 12 12 75 2.92 2.54 2.43
14.54 406 5.76 17.20 390 6.56 18 18 64 4.43 3.06 2.63
115.03 114 12.83 260.73 55 14.01 5 7 87 3.91 3.12 2.67
98.04 141 13.48 231.45 51 11.61 6 8 87 2.52 2.86 2.61
43.73 295 12.61 132.29 80 10.35 7 8 85 3.15 2.99 2.67
43.69 178 7.59 58.44 166 9.48 9 10 80 3.61 3.08 2.72
11.78 248 2.86 29.96 281 8.22 14 13 73 3.51 3.22 2.80
18.68 312 5.68 26.22 249 6.37 17 13 70 3.62 3.30 2.86
23.22 220 4.99 30.36 189 5.59 13 11 76 2.88 3.19 2.85
9.96 263 2.56 27.91 268 7.29 15 13 73 3.09 3.19 2.87
17.99 325 5.71 46.52 165 7.48 10 9 82 2.35 2.96 2.80
17.08 279 4.65 23.08 253 5.71 18 14 68 2.79 2.97 2.81
63.24 226 13.95 141.14 96 13.21 8 10 82 2.87 2.97 2.82
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
70.08 128 8.79 89.39 104 9.10 10 11 80 3.90 3.15 2.89
10.79 239 2.52 15.24 210 3.13 19 15 66 3.42 3.10 2.89
8.28 371 3.00 8.63 281 2.37 22 19 58 4.95 3.63 3.10
16.74 229 3.74 25.50 258 6.43 13 13 74 3.21 3.40 3.05
56.49 257 14.15 165.19 76 12.33 8 9 84 2.84 3.27 3.03
388.41 35 13.18 1831.45 7 13.32 2 6 92 2.03 2.98 2.93
134.65 108 14.20 553.44 25 13.50 4 7 89 1.83 2.75 2.85
361.80 40 13.99 1787.87 8 14.08 3 5 92 1.81 2.55 2.76
194.84 80 15.30 1907.15 8 14.31 3 6 90 1.66 2.40 2.69
119.10 126 14.62 1916.43 8 14.13 3 6 90 1.82 2.31 2.63
146.52 106 15.16 1350.84 10 13.24 4 6 89 1.68 2.18 2.56
331.04 37 12.06 1601.09 8 12.82 3 5 92 2.33 2.25 2.56
23.69 177 4.10 32.10 163 5.12 7 10 83 2.62 2.34 2.57
37.19 191 6.95 42.84 174 7.26 5 7 87 2.51 2.33 2.54
16.22 385 6.09 25.11 207 5.08 10 11 79 2.27 2.31 2.52
28.49 453 12.59 88.43 99 8.57 5 8 87 1.86 2.16 2.45
32.10 125 3.93 34.96 98 3.36 8 10 82 1.66 2.04 2.39
24.24 201 4.76 31.22 128 3.91 10 11 78 1.73 1.96 2.33
19.97 198 3.87 23.85 152 3.55 11 12 76 2.20 2.05 2.33
10.33 222 2.24 40.72 97 3.85 11 12 77 3.38 2.40 2.44
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
15.12 178 2.63 19.22 143 2.69 14 13 73 3.75 2.62 2.52
34.97 70 2.38 10.28 795 7.98 13 14 72 4.62 3.01 2.67
22.81 322 7.17 46.37 101 4.56 9 10 81 5.16 3.40 2.83
21.70 177 3.75 63.06 106 6.56 10 9 81 3.10 3.15 2.77
14.52 230 3.26 46.13 85 3.82 10 10 81 2.49 2.99 2.74
36.36 178 6.31 44.22 126 5.42 8 10 81 3.32 3.16 2.82
52.13 126 6.44 56.75 107 5.91 8 10 81 3.17 3.09 2.81
34.33 136 4.55 35.91 115 4.02 9 11 80 2.81 3.01 2.80
172.43 85 14.37 484.93 28 13.19 4 7 89 2.11 2.76 2.72
47.45 206 9.54 398.43 22 8.59 5 7 87 1.68 2.54 2.64
24.46 212 5.07 25.72 164 4.13 11 11 78 2.25 2.57 2.64
39.41 332 12.78 139.29 76 10.32 6 8 85 2.79 2.65 2.67
181.18 114 20.24 892.96 16 14.24 3 6 91 2.28 2.52 2.62
135.27 69 9.09 1505.24 9 13.06 3 6 91 2.22 2.47 2.59
131.72 139 17.89 1604.86 8 12.85 3 7 90 1.68 2.26 2.50
304.11 27 7.95 1064.82 12 12.96 3 5 92 1.73 2.19 2.46
372.37 49 17.74 1625.30 9 14.05 2 6 92 1.63 2.08 2.39
103.94 96 9.70 1306.21 10 12.84 4 6 90 1.21 1.88 2.30
170.63 64 10.71 167.92 78 12.76 4 6 90 1.56 1.84 2.25
51.08 205 10.24 362.64 24 8.39 8 7 84 2.16 2.01 2.29
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
184.34 60 10.89 339.59 27 9.10 4 6 90 1.88 1.97 2.25
272.01 56 14.99 1630.83 10 15.32 3 6 92 1.76 1.91 2.21
141.11 70 9.61 533.80 17 8.61 11 8 81 2.37 2.05 2.24
220.33 69 14.86 630.60 23 14.23 13 7 79 2.71 2.23 2.29
9.16 142 1.27 91.97 92 8.25 7 9 84 2.75 2.27 2.30
10.60 115 1.19 17.53 130 2.23 13 14 73 3.38 2.54 2.40
60.69 257 15.25 416.00 35 14.02 10 7 83 2.82 2.55 2.41
89.69 134 11.75 463.12 22 10.02 11 7 82 2.08 2.40 2.37
391.26 42 16.06 1882.64 9 15.87 2 6 92 1.37 2.13 2.26
20.63 244 4.91 60.09 65 3.82 8 8 84 1.77 2.13 2.25
132.39 111 14.37 178.85 81 14.12 7 8 85 3.35 2.48 2.37
38.68 208 7.85 49.07 161 7.71 10 11 79 2.36 2.32 2.32
24.91 242 5.89 26.19 239 6.11 13 13 74 2.83 2.46 2.37
10.41 299 3.04 16.42 329 5.28 17 16 67 3.96 2.87 2.52
7.51 328 2.41 18.40 315 5.66 15 15 70 4.48 3.15 2.65
12.58 338 4.15 13.40 317 4.15 18 16 66 4.29 3.32 2.74
12.38 364 4.40 12.98 386 4.89 18 17 64 3.59 3.34 2.79
15.16 352 5.20 15.12 323 4.78 18 17 66 3.98 3.50 2.88
38.70 233 8.79 40.79 228 9.09 12 13 74 4.17 3.65 2.98
24.39 382 9.09 32.15 259 8.12 16 16 69 2.98 3.41 2.93
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
43.94 213 9.15 48.65 187 8.90 10 11 78 2.94 3.33 2.93
25.67 285 7.15 27.34 278 7.42 15 14 71 3.27 3.36 2.97
30.91 244 7.36 35.83 229 8.02 12 13 75 3.20 3.36 2.99
20.61 287 5.78 25.80 330 8.31 16 15 69 2.94 3.31 3.00
15.95 273 4.26 49.62 160 7.74 8 9 83 2.97 3.23 2.99
13.82 385 5.19 9.84 184 1.77 13 11 75 3.66 3.37 3.06
14.37 575 8.06 5.55 203 1.10 15 13 72 3.64 3.37 3.07
6.26 547 3.34 6.53 230 1.47 16 13 71 4.21 3.60 3.18
8.39 576 4.72 8.90 265 2.30 16 15 69 3.46 3.49 3.16
7.25 550 3.90 5.61 178 0.98 14 13 73 2.88 3.33 3.13
5.50 528 2.84 5.36 223 1.17 14 13 73 3.34 3.42 3.17
7.85 562 4.31 5.77 227 1.28 16 14 70 2.83 3.27 3.13
9.91 526 5.09 8.88 544 4.71 15 12 73 3.23 3.27 3.14
5.62 274 1.50 11.14 587 6.39 8 10 82 3.39 3.34 3.17
6.14 465 2.79 24.97 175 4.27 12 12 76 4.01 3.50 3.24
7.38 499 3.60 5.69 200 1.11 13 13 74 3.28 3.40 3.22
11.54 506 5.71 5.63 204 1.12 14 13 74 2.65 3.23 3.17
14.68 371 5.32 6.08 121 0.72 10 11 78 2.59 3.09 3.12
14.41 579 8.15 5.76 229 1.29 15 16 70 2.88 3.10 3.12
15.39 663 9.96 10.92 197 2.10 16 16 69 2.96 3.14 3.14
disk0 disk3 cpu load average
KB/t tps MB/s KB/t tps MB/s us sy id 1m 5m 15m
20.20 425 8.39 6.93 182 1.23 14 13 72 3.29 3.20 3.16
12.74 535 6.66 6.33 217 1.34 16 15 69 3.46 3.29 3.20
13.76 439 5.90 7.70 186 1.40 14 13 73 3.25 3.28 3.20
13.34 158 2.06 13.90 799 10.84 6 10 84 2.62 3.09 3.13
11.06 420 4.54 19.83 200 3.87 9 12 78 2.76 2.99 3.09
7.90 645 4.98 5.54 218 1.18 14 16 70 3.90 3.28 3.19
25.74 483 12.14 32.38 201 6.36 13 15 72 3.88 3.45 3.26
148.51 112 16.17 1288.54 12 15.27 3 9 88 2.47 3.11 3.14
312.58 47 14.20 1581.44 9 14.13 3 8 89 1.95 2.87 3.05
89.49 180 15.75 1870.37 8 14.28 5 10 85 2.25 2.82 3.02
365.67 30 10.61 1775.78 6 10.69 2 8 90 2.36 2.71 2.96
328.22 48 15.26 1572.97 10 15.80 3 8 89 2.41 2.65 2.92
67.35 188 12.39 83.92 133 10.88 6 10 83 2.82 2.76 2.94
80.30 204 16.02 378.58 34 12.39 9 11 80 3.16 2.81 2.95
101.85 133 13.22 917.60 15 13.13 4 9 88 2.38 2.67 2.88
168.53 80 13.09 442.19 34 14.59 5 9 86 2.51 2.64 2.85
362.49 43 15.05 1491.95 10 14.57 3 8 89 2.03 2.48 2.78
55.97 276 15.07 1919.02 6 12.03 4 9 88 2.16 2.46 2.75

[Thomas Kaiser]

Ingrid Kaiser schrieb in <news:slrnla0lhr.14v...@phg-online.de>
> Nun zu Netatalk
> [...]

> Das Ganze überlebt stundenlangen Ruhezustand mitten im Backup, solange
> sich das zu sichernde Device beim Aufwachen _rasch genug_ wieder mit
> dem AFP-Server verbinden kann

Es ist sogar alles viel besser -- siehe unten.

> (wenn ich's richtig beobachtet habe, dann überlebt das sogar einen
> Wechsel des Interfaces -- Deckel zu, LAN abgestöpselt, Stunde später
> wieder aufgeweckt und Backup lief per WLAN weiter. Bin mir aber nicht
> mehr 100% sicher). Wenn nicht, droht halt das übliche zerschossene
> SparseBundle.

Das hab ich mal probiert, hat aber nicht ansatzweise geklappt ... also
das Sparsebundle zu schreddern durch 1a DAU-Verhalten :-)

Backup lief heute früh daheim aufs CubieNAS unterm Sofa (per WLAN).
Deckel vom Macbook zugeschmissen, über die Strasse ins Café, Deckel
wieder auf. Laut system.log fällt es dem Rechner auf und er vermerkt
besorgt, dass da Handlungsbedarf ist, wenn er das nächste mal in die
Nähe vom CubieNAS kommt (konkret: "Open Fork, Byte Range Lock, or Close
Fork still in progress", d.h. das System merkt sich ebenso wie Netatalk
welche Dateien/Forks offen bzw. mit Locks sind):

http://kaiser-edv.de/tmp/9nQgUX/system.log-1.txt

Dann ins Büro (im system.log jammert der backupd jede Stunde "Backup
failed with error: 19") und um halbe sieben wieder daheim Deckel
aufgemacht. MacBook findet WLAN, findet CubieNAS, macht keinen Reconnect
sondern mountet den Kram wieder her und sichert einfach so weiter als
ob nix gewesen wäre:

http://kaiser-edv.de/tmp/9nQgUX/system.log-2.txt

bash-3.2# tmutil status
Backup session status:
{
BackupPhase = Copying;
ClientID = "com.apple.backupd";
DateOfStateChange = "2013-12-05 17:38:59 +0000";
DestinationID = "E3F3946D-F1D0-4FA1-A75E-2BE7648F354B";
DestinationMountPoint = "/Volumes/Time Machine-Backups";
FirstBackup = 1;
Percent = "0.02752094288795243";
Progress = {
TimeRemaining = 37911;
"_raw_totalBytes" = 217573284919;
bytes = 6653135498;
files = 5687;
totalBytes = 239330613410;
totalFiles = 2621708;
};
Running = 1;
Stopping = 0;
"_raw_Percent" = "0.03057882543105825";
}

Dann daheim Deckel wieder zu, Abendessen rinn, um kurz nach acht Deckel
wieder auf und Versuch, TimeMachine <--> CubieNAS zu foppen. Ethernet
(en2) angestöpselt, WLAN (en1) ausgemacht, WLAN wieder an, Reihenfolge
der Interfaces geändert. Stört TimeMachine nicht die Bohne, das macht
einfach noch paarmal Reconnects und sichert weiter, als wäre nichts
gewesen. Jetzt wieder per Ethernet mit um die 17 MByte/sek:

http://kaiser-edv.de/tmp/9nQgUX/system.log-3.txt

bash-3.2# tmutil status
Backup session status:
{
BackupPhase = Copying;
ClientID = "com.apple.backupd";
DateOfStateChange = "2013-12-05 17:38:59 +0000";
DestinationID = "E3F3946D-F1D0-4FA1-A75E-2BE7648F354B";
DestinationMountPoint = "/Volumes/Time Machine-Backups";
FirstBackup = 1;
Percent = "0.3008501762515047";
Progress = {
TimeRemaining = 19242;
"_raw_totalBytes" = 217573284919;
bytes = 72729956795;
files = 67110;
totalBytes = 239330613410;
totalFiles = 2621708;
};
Running = 1;
Stopping = 0;
"_raw_Percent" = "0.334277973612783";
}

Das "Geheimnis" dahinter ist der Reconnect-Mechanismus, konkret "primary
reconnect", damit der sog. "AFP Replay Cache", ein AFP 3.3 Feature,
funktioniert. Und damit sind dann auch solche Spielchen wie "Deckel zu,
stundenlang ganz woanders unterwegs, wieder zurück und Deckel auf" kein
Problem mehr. Ich weiß leider nicht, ab welcher Netatalk-Version das
exakt implementiert wurde und ab wann wirklich robust, dito an welchen
Schräubchen man aktuell sowohl Client- als auch Server-seitig drehen
kann, um die Reconnect-Zeitspannen zu maximieren (im Gegensatz zu einem
"produktiven" AFP-Server, auf den ganze Rudel von Mac-Usern zugreifen
und bei denen man offene Dateien ganz gerne nach einer gewissen
überschaubaren Zeitspanne automatisch schließen läßt, kann einem das bei
seinem eigenen Timemachine-Serverchen ja wurscht sein und man möchte das
Zeitfenster idealerweise so weit aufreißen wie möglich). Vielleicht kann
Ralph da noch mal in die Bresche springen mit Details?

Gruss,

Ingrid, selbstgesprächelnd den Abgang machend...

[Goetz Hoffart]

Thomas Kaiser <Thomas...@phg-online.de> wrote:

> [1] 7-zip-Benchmarks des Wandboard Quad: http://nixdev.com/?p=365

403

> @G�tz, ich hatte Dir ja schon das "Kleingedruckte" geschickt...

Jop: https://s1.hoffart.de/7zip-bench/?itm=45;46

> denke, dass eine halbwegs exakte Einstufung des Wandboard Quad bei

> ca. 2000-2100 @ 1 GHz liegen d�rfte, da 7-zip rein Integer-basiert

> ist und sich demnach armel/armhf bzw. Soft- vs. Hard-Float nicht
> auswirken sollten, siehe
> https://wiki.linaro.org/OfficeofCTO/HardFloat/Benchmarks201205

Prima.

Wegen der Gleitkomma-Monster im Regal wollt ich eh mal noch was daf�r
suchen ... mal sehen, was einigerma�en gut �berall l�uft.

Gr��e
G�tz
--
http://www.knubbelmac.de/

[Thomas Kaiser]

Goetz Hoffart schrieb am 05.12.2013 in <news:1ldfh7j.1bx8z71zkti42N%use...@hoffart.de>

> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> [1] 7-zip-Benchmarks des Wandboard Quad: http://nixdev.com/?p=365
>
> 403

Mift, schon wieder? Dem sein Server ist das Gegenteil von hochverfügbar.
Naja, in dem Artikel geht's im Detail darum, wie man das i.MX6-basierte
Wandboard übertakten kann (läuft standardmäßig inkl. Spannungsanpassung
bis max. 1 GHz. Und er hat's durch Register- und U-Boot-Modifikationen
mit Maximalspannung bei 1,2 GHz am Laufen). Wer anders hat noch 7-zip-
Ergebnisse für ein Wandboard Quad gepostet und ich meinen Kram
hinterher. Im Endrgebnis bleibt's aber eben bei ca. 2050 Zählerchen @
1 Ghz.

>> @Götz, ich hatte Dir ja schon das "Kleingedruckte" geschickt...
>
> Jop: https://s1.hoffart.de/7zip-bench/?itm=45;46

Nee, ich meinte die "Wandboard"-Nachreiche. Wäre schick, wenn Du die mit
2050 aufnehmen könntest in die Liste.

>> denke, dass eine halbwegs exakte Einstufung des Wandboard Quad bei

>> ca. 2000-2100 @ 1 GHz liegen dürfte, da 7-zip rein Integer-basiert

>> ist und sich demnach armel/armhf bzw. Soft- vs. Hard-Float nicht
>> auswirken sollten, siehe
>> https://wiki.linaro.org/OfficeofCTO/HardFloat/Benchmarks201205
>
> Prima.
>

> Wegen der Gleitkomma-Monster im Regal wollt ich eh mal noch was dafür
> suchen ... mal sehen, was einigermaßen gut überall läuft.

Wobei das ja alles irgendwann nur noch komplett in den Wald führt, wenn
man sich vor Augen führt, was alles bei so einem Benchmark
unberücksichtigt bleibt (bspw. sowas wie die "Instruktionstiefe": bei
den Cortex' kann der A7 1, der A9 2 und der A15 3 parallel ausführen --
und dann gibt es jetzt Hybrid-Dinger, die 4 A7 und 4 A15 auf einem SoC
vereinen und je "nach Bedarf" hin- und herschalten. Gerade Software, die
auch nur mal ein bisschen optimiert wurde für die Plattform, auf der sie
laufen soll, wird sich dann völlig anders verhalten, je nachdem welche
CPUs der big.LITTLE-Architektur gerade randürfen). Von den Tücken der
GPU-Acceleration mal ganz zu schweigen :-)

Gruss,

Thomas

[Goetz Hoffart]

Thomas Kaiser <Thomas...@phg-online.de> wrote:

> > Jop: https://s1.hoffart.de/7zip-bench/?itm=45;46
>

> Nee, ich meinte die "Wandboard"-Nachreiche. W�re schick, wenn Du die mit
> 2050 aufnehmen k�nntest in die Liste.

Argl. Im Kopf die �bersicht verloren, merci f�r den Hinweis. Ich war
gedanklich beim Odroid-XU von Hardkernel. So langsam gibt's von den
ARM-Kistchen eine Modellpalette (und Professionalit�t, wie mir scheint)
wie bei den 8-Bittern in den fr�hen und mittleren 80ern. Hauptsache
einen 6502 oder Z80 irgendwo reingeklebt :-)

> > Wegen der Gleitkomma-Monster im Regal wollt ich eh mal noch was daf�r
> > suchen ... mal sehen, was einigerma�en gut �berall l�uft.
>

> Wobei das ja alles irgendwann nur noch komplett in den Wald f�hrt, wenn
> man sich vor Augen f�hrt, was alles bei so einem Benchmark
> unber�cksichtigt bleibt (bspw. sowas wie die "Instruktionstiefe": bei
> den Cortex' kann der A7 1, der A9 2 und der A15 3 parallel ausf�hren --

> und dann gibt es jetzt Hybrid-Dinger, die 4 A7 und 4 A15 auf einem SoC
> vereinen und je "nach Bedarf" hin- und herschalten. Gerade Software, die

> auch nur mal ein bisschen optimiert wurde f�r die Plattform

Aber sicher. Sogar Latenz (FB-DIMMs!) ist letztlich me�bar, wenn man
genau hinschaut. Nur schreibt man dann pro Rechner/Plattform eine
Doktorarbeit (ja, sowas habe ich auch schon in der Hand gehabt -- was
alles als Wissenschaft durchgeht ...).

Dazu kommt ja auch noch, dass gcc zwar inzwischen ganz gut im
Allgemeinen ist, aber je nach Plattform starke Ausschl�ge hat. Und viele
Software selbst heute ��bliche� Dinge wie SSE nicht nutzt, von AltiVec,
MAX-1, 3DNow etc. mal ganz abgesehen, von wenigen Ausnahmen wie oclhash,
john und einigen wenigen anderen abgesehen.

[Thomas Kaiser]

Goetz Hoffart schrieb am 06.12.2013 in <news:1ldg708.1p85i976mhi2oN%use...@hoffart.de>

> Dazu kommt ja auch noch, dass gcc zwar inzwischen ganz gut im

> Allgemeinen ist, aber je nach Plattform starke Ausschläge hat. Und
> viele Software selbst heute »übliche« Dinge wie SSE nicht nutzt, von

> AltiVec, MAX-1, 3DNow etc. mal ganz abgesehen, von wenigen Ausnahmen
> wie oclhash, john und einigen wenigen anderen abgesehen.

Naja, manchmal merkt man's auch nur einfach nicht, dass der Kram genutzt
wird. Beispiel: Core Image -- aber wer wiederum nutzt das schon? ;-)

http://arstechnica.com/apple/2005/04/macosx-10-4/15/

Gruss,

Thomas

[Goetz Hoffart]

Thomas Kaiser <Thomas...@phg-online.de> wrote:

> Naja, manchmal merkt man's auch nur einfach nicht, dass der Kram genutzt
> wird. Beispiel: Core Image -- aber wer wiederum nutzt das schon? ;-)

IT-Blindheit. Es gibt eine andere L�sung, die in jedem Webforum
empfohlen wird (�imagemagick�) und damit ist sie toll. Manches stirbt
nie aus.

> http://arstechnica.com/apple/2005/04/macosx-10-4/15/

Wobei bei Core Image im Vgl. zu Benchmarking jetzt eine Implementation
auf einer anderen Plattform fehlt.

BTW: Dein Wandboard Quad: https://s1.hoffart.de/7zip-bench/?itm=38

[Thomas Kaiser]

Goetz Hoffart schrieb in <news:1ldiday.3u3orm1atr7fkN%use...@hoffart.de>

> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Naja, manchmal merkt man's auch nur einfach nicht, dass der Kram
>> genutzt wird. Beispiel: Core Image -- aber wer wiederum nutzt das
>> schon? ;-)
>

> IT-Blindheit. Es gibt eine andere Lösung, die in jedem Webforum

> empfohlen wird (»imagemagick«) und damit ist sie toll. Manches stirbt
> nie aus.

Im Kontext ImageMagick ja auch immer besonders "lustig": Es wird dann
die Q16-Version genommen (die intern alles mit 16-Bit pro Kanal rechnet
und damit im Schnitt doppelt so lang wie die für 99% des Krams völlig
ausreichende Q8-Version braucht), weil die halt "dabei ist" und der erst
ca. 10 Jahre junge Fork GraphicsMagick ignoriert. Dabei ist meist alles,
was zu tun wäre, die IM-Kommandos simpel mit "gm " zu präfixen. Und die
Resultate (grad wenn man viel macht) können sich sehen lassen:

http://codeascraft.com/2010/07/09/batch-processing-millions-of-images/

>> http://arstechnica.com/apple/2005/04/macosx-10-4/15/
>
> Wobei bei Core Image im Vgl. zu Benchmarking jetzt eine Implementation
> auf einer anderen Plattform fehlt.

Yep. Taugt aber als Benchmark für die IT-Abteilung -- wir hatten mal ein
Projekt, bei dem wir wegen Bildvergleichsgedöns ziemlich viel Bildver-
arbeitung machen mussten. Da Macs "zulässig" waren als wir den Kram
entwickelt haben, also auf Core Image aufgesetzt. Das lief auf unseren
Entwicklungs-MacBooks als auch den später produktiven iMacs "einfach so"
bzw. ohne dass man irgendeine Verzögerung an der Stelle wahrnehmen
konnte. Aber da dann auf einmal "Macs sind keine Server" galt, musste
ich den Kram umbauen. Auf ImageMagick weil "wir unterstützen nur
Standards". Und in Folge rödelte dann halt eine Sun mit 32 Threads
sequentiell herunter, was vorher auf den iMacs quasi in Echtzeit
nebenher geschah (mein Vorschlag, dafür überhaupt gar keine Kisten
separat abzustellen, da dort völlig problemlos die vorhandene Infra-
struktur -- paar hundert Macs und Helios' Toolserver für Loadbalancing
-- als Grid genutzt werden könnte, wurde mit dem Argument "Arbeitsplätze
sind keine Server" abgelehnt [1]. Was bin ich froh, dass ich mit dem
Irrenhaus nix mehr zu tun habe :-)

> BTW: Dein Wandboard Quad: https://s1.hoffart.de/7zip-bench/?itm=38

Verrückt. Zwischen einer Ultra 20 und 'nem N40L. Und mit einem Quad-Core
A15, der mit 8 Threads daherrödelt, kratzt man dann schon an der 6000er-
Marke:

http://www.7-cpu.com

Gruss,

Thomas

[1] Aber gleichzeitig nutzen sie die Arbeitsplätze für Previewerzeugung
für eine zentrale Datenbank. Nachdem die Feindaten _übers Netz_ auf
einen zentralen Server kopiert werden, werden sie sofort wieder
_übers Netz_ zurück auf den Arbeitsplatz geladen, dann mit eher
untauglichen Mitteln eine eher kleine Preview erstellt und diese in
die zentrale Datenbank gesteckt. Das Ganze noch absurder hinzubekommen,
dürfte kaum mehr möglich sein.

[Ralph Boehme]

Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Das "Geheimnis" dahinter ist der Reconnect-Mechanismus, konkret "primary
> reconnect", damit der sog. "AFP Replay Cache", ein AFP 3.3 Feature,
> funktioniert. Und damit sind dann auch solche Spielchen wie "Deckel zu,
> stundenlang ganz woanders unterwegs, wieder zurück und Deckel auf" kein
> Problem mehr. Ich weiß leider nicht, ab welcher Netatalk-Version das

> exakt implementiert wurde ...

2.2.0

> ...und ab wann wirklich robust, ...

2.2.0! :)

> ... dito an welchen

> Schräubchen man aktuell sowohl Client- als auch Server-seitig drehen

> kann, um die Reconnect-Zeitspannen zu maximieren ...

<http://netatalk.sourceforge.net/3.1/htmldocs/afp.conf.5.html>

disconnect time = number (G)
Keep disconnected AFP sessions for number hours before dropping them.
Default is 24 hours.

Gruß
-Ralph