Modifikationen an eibd und rrdtool upstream?

[greentux]

Auf meinem WG sind die im eibd-clients Paket mit drin.

[henfri]

Auf meinem WG sind die im eibd-clients Paket mit drin.

Und wenn ich die auf meinem Ubuntu installieren will?

Gruß,
Hendrik

[greentux]

ich denke immer noch, man müsste das sauber hinbekommen. Ich bin allerdings kein autoconf Profi, der sitzt im Büro allerdings mir gegenüber. Da werde ich mal am 3.1. direkt mal nachfragen.

[makki]

Upstream ists ja gekommen. Nicht unbedingt als fetchj (neue Funktion), sondern als Anpassung von xport (neben xml nun auch json):
..

Ich weiss, 1.3.1 hat so seine Vorteile auf dem WG. Aber was spricht dagegen, die CV das mit xport machen zu lassen, statt fetchj?
xport könntest Du ja in 1.3.x reinpatchen. Auf neueren Plattformen wäre kein Patch notwendig.

Was dagegen spricht, ist das wir fetch (definierte Datenmenge/Auflösung, die grosse Stärke des rrdtool!) haben wollen nicht xport!
Also mal ein paar Zahlen:

wiregate1:~# time rrdtool xport DEF:ds0=/var/www/rrd/28.0936EC010000_temp.rrd:value:AVERAGE XPORT:ds0 | wc -c
16430

real	0m0.128s
user	0m0.012s
sys	0m0.020s

wiregate1:~# time rrdtool fetchj /var/www/rrd/28.0936EC010000_temp.rrd AVERAGE | wc -c
7512

real	0m0.070s
user	0m0.016s
sys	0m0.008s

Übersetzt: xport dauert 128ms vs. 70ms und produziert 16kb vs 7,5kb an Daten (die über die Leitung müssen, geparsed etc..)
Das sind rund 140% bzw. >200%
Jetzt mag man sagen: das spielt ja keine Rolle, kauf ich mir halt nen neuen Quadcore, wenn der Programmierer nicht mit Resourcen umgehen kann
So tickts hier aber nicht und diese Option ist keine, denn Resourcen sind beschränkt (das nächste WG wird eher kleiner als fetter), Strom kostet Geld und diese denke finde ich auch völlig falsch..

Man kanns nicht allen recht machen, es soll schnell sein (das ist es), gleichzeitig aber perfekt portabel (das ist es, auch, läuft auf einem OpenWRT mit 32MB RAM und 8MB Flash!) und dann noch DAU-sicher, damit mans auf dem neuesten Susi/64 ohne jegliches Wissen kompilieren kann -> da beginnt nun der Interessens-konflikt..

Und wenn ich die auf meinem Ubuntu installieren will?

(eibd)
Dann nimmste die perfekt vorgekauten Pakete und baust ihn dir, wie steht oben schon.. Läuft ohne jeglichen Fehler durch..

Sorry, wenn Performance "wurscht" ist, kann man sich easy ein py/bash/perl bauen das rrdfetch und eibread/write entspr. "wrapped" - das posten nicht vergessen - nicht mein Job, ich habs gern in klein & schnell..

Edit: nur noch am Rande, worums geht: 60ms sind verdammt wenig, wurscht, aber wenn man auf einer gewöhnlichen Visu 200 Diagramme hat, sind das mal flockige 200*60ms, also 12 verdammt lange Sekunden Strafzeit beim aufrufen der Visu - nur dafür!
Edit2: @greentux: natürlich kann man das hinbekommen: man patcht einfach das fetchj (ist schön fein säuberlich mit Quilt im Packerl) ins rrdtool 1.4

Makki

[greentux]

Makki, das Argument hast Du auf der rrdtool Liste aber nicht mehr gebracht. Insofern hatten die eigentlich ja keine Chance das doch upstream zu bringen. Die haben Deine Anforderung "ich will JSON direkt raushaben" eingebaut. Du hattest da ein fetch vorgeschlafen, die haben es mit xport gemacht. Dann war Ruhe.

Also gibts jetzt nen eigenen Patch und basta. Bitte dann nicht dauernd rummäkeln, das der Upstream Kram so "schlecht" ist.

[henfri]

(eibd)
Dann nimmste die perfekt vorgekauten Pakete und baust ihn dir, wie steht oben schon.. Läuft ohne jeglichen Fehler durch..

Beim Eibd mag das sein, da mag ich was verbockt haben.
Aber beim rrdtool sind wir ja wohl beide gescheitert.

Dennoch&nochmal: Was spricht dagegen, die zwei Miniprogramme als *.c, makefile&co mitzuliefern?

Sorry, wenn Performance "wurscht" ist, kann man sich easy ein py/bash/perl bauen das rrdfetch und eibread/write entspr. "wrapped" - das posten nicht vergessen - nicht mein Job, ich habs gern in klein & schnell..

Das wäre ja eine Option: dieses Skript könnte dann mit der CV mitgeliefert werden. Wer mehr Performance braucht kann dann Entscheiden, ob er 1mal 5h mit rrdtool, ruby&Co Zeit verbringt, oder täglich 0.7s an der Visu für den Rest seines Lebens (ich sehe ein, dass 0.7 s sehr störend sein können!)

Gruß,
Hendrik

[greentux]

Henfri, ich habe gerade kein aktuelles rrdtool mit ner CV im Haus

Du könntest Dir ein

-rwxr-xr-x 1 user user     707 27. Dez 22:53 rrdfetch

ins cgi-bin legen.
Das könnte so aussehen:

#!/bin/sh
#echo Content-Type: text/plain
echo Content-Type: application/json
echo Content-Encoding: gzip
echo

#rrdtool fetch /var/www/rrd/Luftfeuchte_Bad_knx5-2-79.rrd AVERAGE -s-24h
RRD=`echo "$QUERY_STRING" | sed -n 's/^.*rrd=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`
DS=`echo "$QUERY_STRING" | sed -n 's/^.*ds=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`
START=`echo "$QUERY_STRING" | sed -n 's/^.*start=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`
END=`echo "$QUERY_STRING" | sed -n 's/^.*end=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`
RES=`echo "$QUERY_STRING" | sed -n 's/^.*res=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`

#FIXME: check path traversal

rrdtool xport -json /var/www/rrd/$RRD $DS -s$START -e$END -r$RES | gzip -c

Ich weiss nicht, ob die Parameter für xport den fetch entsprechen. Laut Doku rrdtool könnte es so sein.
Das Script oben ist das vom WG, ausser einer kleiner Anpassung in der letzten Zeile.
Damit "könnte" Diagramme schon gehen.
Wenn auch mit Performance und Paketoverhead...

[makki]

Makki, das Argument hast Du auf der rrdtool Liste aber nicht mehr gebracht. Insofern hatten die eigentlich ja keine Chance das doch upstream zu bringen. Die haben Deine Anforderung "ich will JSON direkt raushaben" eingebaut. Du hattest da ein fetch vorgeschlafen, die haben es mit xport gemacht. Dann war Ruhe.

Nun, ich hatte das schon explizit gesagt (u.a. auch in direkter Kommunikation) und Tobi Oetiker kennt sicher den Unterschied zwischen fetch und xport
Aber wenns nicht sein soll, hmm, dann darf ich auch mal Stur sein und es eben so machen wie ich es für richtiger halte..

Der eigentliche Kernpunkt: auf nem X-Core muss man sich wie du schreibst nur einen kleinen Wrapper bauen, der kann gerne ins CV-Packerl aufgenommen werden, fertig..
rrdtool 1.4+ ist wie du ja weisst keine Option, weil das (ich vermute wegen libgd vs. cairo) ist nochmal Faktor 10 langsamer, das geht garnicht..

Makki

[henfri]

Henfri, ich habe gerade kein aktuelles rrdtool mit ner CV im Haus

Du könntest Dir ein

-rwxr-xr-x 1 user user     707 27. Dez 22:53 rrdfetch

ins cgi-bin legen.
Das könnte so aussehen:

Wow, das ging schnell!
Hab ich gemacht.

Antwort-HeaderFormatiert anzeigen
HTTP/1.1 200 OK Content-Type: application/json Content-Encoding: gzip Transfer-Encoding: chunked Date: Thu, 27 Dec 2012 22:09:05 GMT Server: lighttpd/1.4.28  Anfrage-HeaderQuelltext anzeigen
Accepttext/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Encodinggzip, deflateAccept-Languagede-de,de;q=0.8,en-us;q=0.5,en;q=0.3Connectionkeep-aliveCookieSqueezebox-expandPlayerControl=true;  Squeezebox-expanded-MY_MUSIC=0; Squeezebox-expanded-RADIO=0;  Squeezebox-expanded-PLUGIN_MY_APPS_MODULE_NAME=0; Squeezebox-expanded-FAVORITES=0; Squeezebox-expanded-PLUGINS=0; Squeezebox-player=00%3A04%3A20%3A17%3Ae7%3A08Host192.168.178.3User-AgentMozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0

Es scheint -was firebug angeht- kein Fehler aufzutauchen. Aber es wird auch kein Bild angezeigt.

Gruß,
Hendrik

[henfri]

Der eigentliche Kernpunkt: auf nem X-Core muss man sich wie du schreibst nur einen kleinen Wrapper bauen, der kann gerne ins CV-Packerl aufgenommen werden, fertig..
rrdtool 1.4+ ist wie du ja weisst keine Option, weil das (ich vermute wegen libgd vs. cairo) ist nochmal Faktor 10 langsamer, das geht garnicht..

Na, aber mit der CV ist doch nicht nur die Zielgruppe der kleinen Kisten anvisiert. Diejenigen (die Maintainer der kleinen Kisten, so wie du Makki) kommen mit dem ganzen Kram schon klar. Aber für alle anderen wäre es schon super, eine einfachere Lösung zu haben

Wie gesagt: Es geht nicht um Binaries (worum es geht hab ich ja mehrmals schon geschrieben).

Mal was anderes:
Gibt es in Distributionen wie Debian/Ubuntu, Suse und Co keine Möglichkeit zu sagen: Installier mir das Paket (geht) vom Source (geht, z.B. bei Debian, Gentoo) aber mit diesem Patch.diff.

Dann könnte man mit der CV einfach eine Diff für rrdtool und auch für den eibd (der aber ja kein Patch ist, sonder einfach zur zwei, drei *.c Dateien erstellt)

Gruß,
Hendrik

[greentux]

Das soll die Anwort sein henfri? Was macht der ganze Squeezeboxkram da?

[greentux]

Alles zurück henfri. Das xport ist wesentlich mächtiger als das fetch. Das wird heute Abend nix mehr...

[greentux]

henfri, kannst du mir ggf. mal ein rrd hier anhängen, was unter 64 bit erzeugt wurde?

[callidomus]

Alles zurück henfri. Das xport ist wesentlich mächtiger als das fetch. Das wird heute Abend nix mehr...

Wieso vergisst Du nicht das xport und verwendest nur das fetch und jsonised das dann? Das wird doch von der CV erwartet, oder?

In eine höherwertigen Scriptsprache ein Dreizeiler ;-)

[greentux]

Weil Scriptsprache wieder Scriptsprache
Dauerts ja noch länger... oder?
Ausserdem kann ich gut und gerne man-pages lesen und Scripte anpassen, aber kein Python oder Co.