Knoten und Topo Probleme (neue Topographie Beitrag #31)

[tox]

Werden die Nodelisten im Wiki eingentlich auch wieder die Botinfos einsammeln?

Steht auf der ToDo-Liste.

[tmk]

und siehst du die 15.18 in deiner datenbank da?

[4huf]

An das alte Sammelscript kommt man wohl nicht mehr ran ?
Die 5GHz-Strecke wird z.Z. auch nicht erfasst .
In einem anderen Posting stand was von botinfo.
Ich vermute "cgi-bin-botinfo.txt" ?
Leider ist die Firmware auf den 5GHz-Routern eine uralte Kamikaze mit spezieller
Einstellung der atheros-Treiber und das Webinterface
aus Teilen der uralten FF-Firmware zusammengebastelt.
Zum einen gab es damals die cgi-bin-botinfo.txt noch nicht und zum anderen wird vermutlich
das OLSR-Text-Plugin benötigt. Das fehlt aber leider auch, so das es schwer wird
das nachzubasteln.
Das alte Sammelscript konnte aber mit den vorhandenen Infos leben.
Ein Neubau das 5GHz-Strecke ist recht aufwendig ...

[3dfxatwork]

Ich stelle noch dieses Wochenende eine Version von Botinfo online, damit möglichst alle Router erfasst werden können.

Edit: Wie gefällt das neue Design der FFHTopo also der Karte ?
Die Virtual Earth ansicht funktioniert leider noch nicht, da kommt ein JavaScriptfehler, jedoch liegt das Skript auf einem Microsoft Server, wahrscheinlich haben die was an der Api geändert, das ergründe ich aber mal einen anderen Tag.

mfg matthias

[tmk]

Gelb fetzt.

[HotShot]

Könntet ihr noch Zoom per Mausrad hinzufügen?

map.enableScrollWheelZoom();

[tox]

und siehst du die 15.18 in deiner datenbank da?

Nein, ist nicht erreichbar.

An das alte Sammelscript kommt man wohl nicht mehr ran ?

Das wäre nicht das Problem. Die Umstellung hatte die beiden Absichten, zum einen zumindest so gut es geht uns von Scripten zu verabschieden, denn diese sind (meiner ganz persönlichen Meinung nach!) schlecht dokumentiert und daher schlecht wartbar. Ich bin der Meinung, dass uns eine debugbare Hochsprache in der Hinsicht deutlich voranbringt. Zum anderen beabsichtigten wir die Komplettumstellung von MySQL auf Postgres, ich habe weder Ahnung, ob das in Python einfach umzustellen geht, noch von Python selbst.

Die 5GHz-Strecke wird z.Z. auch nicht erfasst .
In einem anderen Posting stand was von botinfo.
Ich vermute "cgi-bin-botinfo.txt" ?
Leider ist die Firmware auf den 5GHz-Routern eine uralte Kamikaze mit spezieller
Einstellung der atheros-Treiber und das Webinterface
aus Teilen der uralten FF-Firmware zusammengebastelt.
Zum einen gab es damals die cgi-bin-botinfo.txt noch nicht und zum anderen wird vermutlich
das OLSR-Text-Plugin benötigt. Das fehlt aber leider auch, so das es schwer wird
das nachzubasteln.
Das alte Sammelscript konnte aber mit den vorhandenen Infos leben.
Ein Neubau das 5GHz-Strecke ist recht aufwendig ...

Ja, cgi-bin-botinfo.txt ist richtig. TxtInfo wird auf den Knoten nicht benötigt, zumindest nicht für die Informationen, die wir abrufen. Im Wesentlichen wird durch BotInfo der NVRAM veröffentlicht. Es wäre wahrscheinlich kein Problem, diese Datei auf den 5-GHz-Knoten zu installieren.

Ich stelle noch dieses Wochenende eine Version von Botinfo online, damit möglichst alle Router erfasst werden können.

Ich benötige bitte die Kategorien nvram, wlan (abschnitt wlan_rate) und routes.

Könntet ihr noch Zoom per Mausrad hinzufügen?

map.enableScrollWheelZoom();

Ok, auf der ToDo-Liste.

[4huf]

Ich meinte das man in dem alten Sammelscript nachsehen könnte wie das da gelöst war.
Dieses Sammelscript war über einige Zeit gewachsen und es waren einige Besonderheiten berücksichtigt.
Aber wenn es weg ist hat sich das erledigt ...

Im neuen Script sollten ev. auch ein paar Plausibilitätstests rein, so das z.B. sowas wie mit der
"Mono-14_15" nicht die ganze Karte verhaut.

Ich benötige bitte die Kategorien nvram, wlan (abschnitt wlan_rate) und routes.

Bitte Vorsicht ! gerade NVRAM wird aussterben.
Alle auf Kamikaze basierende Router haben keinen NVRAM mehr.
Ich hab mich noch nicht so intensiv mit der neuen Freifunk-Firmware befasst. Darum
weiß ich jetzt nicht was da an Infos rausgegeben wird wo die her kommen.
(oder ob da so eine botinfo noch fehlt)
Könntest du mal genauer definieren welche Infos benötigt werden ?
"routes" ist kein Problem.
"wlan_rate" kann man nachbilden, allerdings bringt das nicht auf allen Nodes sinnvolle Ergebnisse
siehe "Bit Rate" auf http://104.62.5.2/cgi-bin/cgi-bin-status.html bzw. http://104.62.5.1/cgi-bin/cgi-bin-status.html
Wie das auf Routern mit Atheros und AdHoc-Mode aussieht weiß ich jetzt nicht (tmk ?)
Für die Karte werden ja aber auch die LQ/NLQ bzw ETX-Werte benötigt.
Wie werden die gesammelt? Hier fehlt mir wie gesagt auf den 5GHz-Nodes das OLSR-Text-Plugin. Es ist nur das OLSR-HTML-Plugin unter http://104.62.5.2:8080 bzw http://104.62.5.2:8080/nodes verfügbar.
Reicht die Table "Links" ? das könnte ich ja ev. nachbauen.

Edit: so die ersten Teile sind verfügbar.
Allerdings gibt es ein weiteres Problem. Aus unerfindlichen Gründen lässt der http-Server
keine Scripte unter /www bzw http://104.62.5.1/ zu.
Deshalb sind alle Seiten unter /www/cgi-bin bzw. http://104.62.5.1/cgi-bin
Für normale Browser kein Problem da die per index.html umgeleitet werden.
Für das Sammelscript hab ich aber noch keine Idee.

[3dfxatwork]

Zum Edit: Das liegt an der Busybox Version, in neueren Versionen müssen Skripte unter "cgi-bin/" liegen, bei alten reichte "cgi-bin", also es musste kein Ordner sein.

[4huf]

Das liegt an der Busybox Version

Das habe ich befürchtet.
Leider ist das wie gesagt eine alte Kamikaze (bleeding edge, r8171)
Um da was neu zu machen müsste die 5GHz-Strecke abgebaut werden und
ich müsste sehen das ich da ein neues Buildsystem aufsetzten kann.
(der WHR108 wird aber nicht direkt unterstützt)

Es wäre schön wenn es eine Möglichkeit gäbe das die 5GHz-Strecke trotzdem in der Karte
erscheint. Mit dem alten Sammelscript ging es ja ...

[Basti7]

Morgen Kollegen

also erstmal danke für die geniale map, sehr schick auch mit dem FF-Design!!!
Ich hab nun auf den von mir eingerichteten Knoten im Paulusv. die GPS-Koordinaten eintragen lassen allerdings obwohl dies nun schon 2 Tage her ist, erscheinen die Knoten nicht in der Karte.
Ich hab die Koordinaten wie immer nach dem alten Prinzip (z.B.: 51.491987726148594 11.976630538702011) bei Kontaktinfos -> GPS eingetragen und übernommen...
hab ich etwas übersehen?
Grüße und euch ne schöne Woche!

Basti!

[SiggiZ]

Morgen Kollegen

Ich hab die Koordinaten wie immer nach dem alten Prinzip (z.B.: 51.491987726148594 11.976630538702011) bei Kontaktinfos -> GPS eingetragen und übernommen...
hab ich etwas übersehen?

Ja, ein ";". Ein "51;11" sollte dann schon sein.

[Basti7]

asso, ähhh... ging das nicht früher auch mit nur nem Leerzeichen?
komisch ich habs vor 5 Std. auf: 51.491987726148594;11.976630538702011 geändert aber der Knoten taucht noch immer nicht auf. Normalerweise waren Änderungen nach ca. 30min. auf der Karte, dauert das jetzt etwas länger oder hab ich immernoch was falsch

[tmk]

Vielleicht dauert das ein bisschen ehe die Topogrohie das merkt? Die 14.14 und 14.15 sind ja noch in Nebra, Cyrus hat gestern vor meinen Augen die Koordinaten der 14.14 korrigiert (bitte die 14.15 auch noch machen!) und sie hängt immer noch da unten rum...

[Basti7]

Hmm ok… wie gesagt früher wurden Änderungen innerhalb von ca. 30min. übernommen (sehr praktisch beim Standort testen und Antenne ausrichten
tox wie oft wird die map so ca. aktualisiert?

[tmk]

Das wird bestimmt auch wieder regelmäßiger... Dem VServer fehlt RAM, wenn ich tox richtig verstanden habe.

[tox]

@4huf das ist ganz einfach, wie das in dem Sammelscript gelöst war. Es hat die Weboberfläche mit einem regulären Ausdruck ausgewertet und sich die Daten zusammengesucht. Diese Methode, formale Daten über eine für Menschen bestimmte Webseite zusammenzusuchen, finde ich ziemlich russisch (Wenn sich die Webseite ändert, kann es dir das Script zerhauen), sodass ich das gar nicht erst anfangen mochte.

Zu den Plausibilitätstests. Ich hab bereits eingebaut, dass fehlerhafterweise vertauschte GPS-Koordinaten umsortiert werden. Das finde ich das Maximum an Eingriff, den ich an den Daten vornehmen sollte. Weiterführende Änderungen in Bezug zu z.B. der Sache mit der Mono-14_15 würde doch dazu führen, dass zum einen die Darstellung zum großen Teil nur noch aus Fehlerverschleierung besteht, und man gar nicht mehr abschätzen kann, welche Daten jetzt der Praxis entsprechen und welche zur reinen Schönung der Darstellung dazuinterpretiert wurden, und dass zum anderen solche Fehler nicht entdeckt werden. Je eklatanter nämlich solche Fehler sind, desto mehr ist der einzelne bereit, sich mit demjenigen, der solche fehlerhaften Angaben in seinem Knoten stehen hat, in Kontakt zu setzen, um das zu berichtigen.

Dass NVRAM aussterben wird macht dem Tool insofern nichts aus, als dass die cgi-bin-botinfo.txt nur entsprechend angepasst werden müsste, dass es sich die Daten woanders in einer passenden Form zusammensucht.

BotInfo benötigt die Infos wie z.B. hier gezeigt. Aus routes benötige ich nur die Zeile

Code: Alles auswählen

	default via 192.168.178.1 dev vlan1

von wlan brauch ich nur den wlan_rate-Abschnitt, der mir die aktuelle Übertragungsgeschwindigkeit mitteilt. Vom NVRAM brauch ich auch nur ein Paar Werte, die mit ff_adm beginnen (die Kontaktdaten), dann wl0_channel, boardtype, boardnum, wan_hostname und ff_release.

Die LQ- und NLQ-Werte werden direkt von OLSRD gesammlt, dann über OLSR dem Server mitgeteilt und dort werden sie per TxtInfo ausgelesen, die Daten sind hier einsehbar. Du brauchst also kein TxtInfo-Plugin auf den Knoten.

Die Sache mit dem cgi-bin-Ordner soll auch kein Problem sein, dann überprüfe ich beim Sammeln der Daten halt beide Pfade.

@GPS-Koordinaten Ja, ich fänds schön, wenn jeder User die GPS-Koordinaten nach Spezifikation eintragen würde, aber dann würde halb Halle nicht auftauchen in der Karte. Daher hab ich das etwas toleranter gebaut, sodass auch Leerzeichen als Trennzeichen dienen können.

@Aktualisierung

Das wird bestimmt auch wieder regelmäßiger... Dem VServer fehlt RAM, wenn ich tox richtig verstanden habe.

Genau, ich mach das "Update" nur in der Nacht, um Fehlermeldungen von Board und Wiki aus dem Weg zu gehen, und auch das bislang auch eher unregelmäßig. Werd ich heute Nacht wohl mal wieder machen. Kann auch jeder andere Admin starten, dazu in mein Home gehen, dort "mono NIC/NIC.exe" starten, dauert etwa 3 bis 5 Minuten.

edit. Zoom per Mausrad wurde hinzugefügt, ist aber sehr träge.

[4huf]

Es hat die Weboberfläche mit einem regulräen Ausdruck ausgewertet und sich die Daten zusammengesucht.

Viel mehr als cgi-bin-contact.html kann das nicht gewesen sein.
Und das wird ja jetzt durch cgi-bin-botinfo.txt?cat=nvram abgelöst.
Läst sich ja leicht nachbilden.

Code: Alles auswählen

nvram{
	ff_adm_latlon=51.48196897868616;11.92342758178711
	ff_adm_mail=freifunk-halle@arcor.de
	ff_adm_loc=Neustadt
	ff_adm_nick=5GHz-2
	ff_adm_name=Ingo
	ff_tz=MET-1MEST-2,M3.5.0,M10.5.0
}

Bei den Plausibilitätstests meine ich das solche falschen Nodes garnicht erst angezeigt werden.
Ob da Müll oder nichts drin steht kommt ja auf das selbe raus ...
Was ist eigentlich z.Z. der Unterschied ob die Koordinaten grün oder rot angezeigt werden ?
Früher waren die roten Koordinaten "ungeprüfte" z.B. aus Strasse/Hausnummer
(oder vom Admin erstellte ?) Koordinaten.
Aber z.Z. die falschen von Mono-14_15 sind auch rot.
(oder z.B. 104.62.30.10)

Die LQ- und NLQ-Werte werden direkt von OLSRD gesammlt, dann über OLSR dem Server mitgeteilt und dort werden sie per TxtInfo ausgelesen, die Daten sind hier einsehbar. Du brauchst also kein TxtInfo-Plugin auf den Knoten.

Das heißt vom OLSRD auf dem Tunnel-Server oder wo läuft der OLSRD ?
Warum erscheinen die 104.62.5.x nicht in der Auswahlliste ? Weil noch keine Koordinaten dafür gesammelt wurden ?
Aber auch die 104.62.7.9 mit Koordinaten ist nicht da.

Die Sache mit dem cgi-bin-Ordner soll auch kein Problem sein, dann überprüfe ich beim Sammeln der Daten halt beide Pfade.

Das wäre sehr schön.

Code: Alles auswählen

Genau, ich mach das "Update" nur in der Nacht, .. und auch das bislang auch eher unregelmäßig.

Es wäre ev. nicht schlecht neben der Zeit auch das Datum (Tag/Monat) der letzten Aktualisierung mit an zu zeigen. Das verhindert Irritationen, auch wenn das Script später man aus welchen Gründen auch immer nicht läuft.
An der rechten Legende müsste sowiso noch mal Hand angelegt werden.
Seit dem Update mit dem Design stimmt die Größe nicht mehr und je nach Text und Browser werden die Auswahlboxen für die Links von der Fußzeile verdeckt.
(heute mit FF 3.5.2 OLSR nicht erreichbar, mit IE8 gerade so)

Ist es eigentlich Absicht das kein Swap auf dem Server existiert.
Das würde ja bei Speicherproblemen etwas helfen.

[tox]

...

Viel mehr als cgi-bin-contact.html kann das nicht gewesen sein.

Genau, und die cgi-bin-status.html.

Bei den Plausibilitätstests meine ich das solche falschen Nodes garnicht erst angezeigt werden.
Ob da Müll oder nichts drin steht kommt ja auf das selbe raus ...

Genau das ist die Sache. Man müsste irgendwie definieren, was falsch ist. Und wenn dann tatsächlich mal ein Knoten in Nebra oder Leipzig steht, wird er fälschlicherweise entfernt. Das fände ich nicht gut. Wie gesagt, ich bin dafür, dass wir beim Auftauchen solcher "merkwürdiger" Verbindungen, besser mit der Kontaktperson reden und den Fehler zu korrigieren (falls es denn überhaupt einer ist), anstatt ihn gar nicht erst zu entdecken.

Was ist eigentlich z.Z. der Unterschied ob die Koordinaten grün oder rot angezeigt werden ?
Früher waren die roten Koordinaten "ungeprüfte" z.B. aus Strasse/Hausnummer
(oder vom Admin erstellte ?) Koordinaten.
Aber z.Z. die falschen von Mono-14_15 sind auch rot.

Mh, gute Frage, das hab ich nicht eingestellt. Offenbar spiegelt diese Farbgebung die Genauigkeit der Koordinaten wider. Orange ist alles mit weniger als 10 Nachkommastellen.

...

Das heißt vom OLSRD auf dem Tunnel-Server oder wo läuft der OLSRD ?

Das OLSRD auf deinen Knoten tauscht sich mit allen anderen Knoten in der Umgebung über mögliche Verbindungen aus. Dabei werden diese Informationen übertragen.

Warum erscheinen die 104.62.5.x nicht in der Auswahlliste ? Weil noch keine Koordinaten dafür gesammelt wurden ?
Aber auch die 104.62.7.9 mit Koordinaten ist nicht da.

Genau, es werden vor der Übermittlung alle Knoten ohne Koordinaten entfernt. Die 104.62.7.9 erschien bisher nicht, weil die angegebenen Koordinaten fehlformatiert sind. Da ist ein Leerzeichen vor der geographischen Breite, welches man in der cgi-bin-contact.html nicht sieht. Eine tolerantere Version des Datensammlers lag heute schon bereit und mit ihr wurde das Update eben gemacht, sodass die Koordinaten ermittelt wurden.

Code: Alles auswählen

...

Es wäre ev. nicht schlecht neben der Zeit auch das Datum (Tag/Monat) der letzten Aktualisierung mit an zu zeigen. Das verhindert Irritationen, auch wenn das Script später man aus welchen Gründen auch immer nicht läuft.

Mh nun, das Ziel der Anwendung ist es ja eigentlich, dass die Daten ständig aktuell sind eben nicht von einem bestimmten Datum. Außerdem gebe ich der Topographie schon das Datum der letzten jeweiligen Aktualisierung mit, sie wird nur nicht direkt angezeigt. Ich weiß jetz auch gar nicht direkt, wo die verwendet wird... Ich würde sagen, wir belassen es zunächst dabei bis zum Regelbetrieb des Datensammelprogramms und schaun dann weiter, wie sich das entwickelt. Die Sache ist nämlich die, ich könnte dran schreiben, dass das Programm das letzte Mal vor 6 Minuten gelaufen ist, was aber nicht bedeutet, dass die angezeigten Daten sämtlich von vor 6 Minuten sind. Darüber gibt dieses ominöse Attribut jedes Knotens Auskunft, das ich mit übertrage und von dem ich nicht weiß, wo es verwendet wird.

An der rechten Legende müsste sowiso noch mal Hand angelegt werden.
Seit dem Update mit dem Design stimmt die Größe nicht mehr und je nach Text und Browser werden die Auswahlboxen für die Links von der Fußzeile verdeckt.
(heute mit FF 3.5.2 OLSR nicht erreichbar, mit IE8 gerade so)

Das ist mir auch aufgefallen. Ich geb diese Aufgabe mal ganz gekonnt an 3dfx weiter

Ist es eigentlich Absicht das kein Swap auf dem Server existiert.
Das würde ja bei Speicherproblemen etwas helfen.

Stimmt auffallend, darum wollte sich 3dfx auch kümmern.

[zuw2]

Ist es eigentlich Absicht das kein Swap auf dem Server existiert.
Das würde ja bei Speicherproblemen etwas helfen.

Stimmt auffallend, darum wollte sich 3dfx auch kümmern.

Dass mit free kein swap reported wird, ist nicht ungewöhnlich.Siehe http://wiki.openvz.org/Swappages#swappages Swap wird wahrscheinlich trotzdem genutzt.

Der Swapspace wird vom Hardware Node verwaltet und ist damit auch abhängig vom guten Willen des HardwareNode-Admins. Also das gleiche wie beim RAM. Wenn man sich die User Bean Counters anguckt, müsste man den zur Verfügung stehenden Swap Space ausrechnen können.

Soweit ich weiß, kannst du in einem Openvz-Container gar kein Swap anlegen. Ich hab es eben mal trotzdem testweise und erfolglos mit einem Swapfile innerhalb des Conainers probiert:

Code: Alles auswählen

swapon ./swapfile
swapon: ./swapfile: Operation not permitted

[3dfxatwork]

Ja ich weiß das man in Openvz keinen Swap anlegen kann, wir haben jetzt nochmal den RAM erhöht, mal sehen ob es jetzt reicht

[tox]

Guck mal, 4huf, die 5-GHz-Nodes sind in der Karte Nur die ff_adm_nick-Felder haben noch einen falschen Inhalt, da sollte der Spitzname drin stehn.

Wir haben das Layout der Karte noch ein wenig verbessert. Es sollte jetzt zu keinen größeren Problemen mehr kommen. Die Virtual-Earth-Ansicht hat Schwierigkeiten mit den Größenangaben. Es kann passieren, dass rechts und unten in der Darstellung die Karte nicht gezeichnet wird. Das liegt zum einen daran, dass die Ansicht bei jeder Größe von derjenigen Größe ausgeht, die der Kartenbereich beim Laden hatte, zum anderen lässt sich die Breite auf keinen anderen festen Wert als 600 Pixel einstellen. Bei variabler Größe geht die Karte wie gesagt wiederum von diesem Wert aus.

[tmk]

edit. Zoom per Mausrad wurde hinzugefügt, ist aber sehr träge.

Tolle Sache, bei mir zu Hause laggt das auch ein wenig, ist aber machbar. Habs in der Uni auf den Mac Pros (2 mal Dual Xeons mit viel RAM und wasweißichvielviele-Mbits Standleitung) getestet, rennt tadellos.

[4huf]

Danke für die Arbeit, die Karte geht nun wieder fast perfekt.
Das einzige was ich nun noch zu bemängeln hätte wäre der Kartenausschnitt.
Ich hab hier nur eine Auflösung von 1024x786 auf dem Notebook.
Wobei das ja keine unübliche Auflösung ist.
Dabei sind die Nodes 30.10 kurz unter der Mitte.
Dadurch ist der untere Bereich praktisch leer.
Deliz am Berge ist nicht mehr drauf.
Am oberen Rand sind die Nodes in der Höhe von 14.48 abgeschnitten.
Wenn man Deliz am Berge mit drauf haben will hilft wohl nur eine Zoomstufe kleiner.
Wenn man darauf verzichtet sollte der Ausschnitt etwas verschoben werden, so das Halle
bis zur Trothaer Str. zu sehen ist.

In einem 1272x914 Fenster (VMWare Fenster ) passt natürlich, das sind alle Nodes drauf.

[PapaBaer]

So, ich weiß, dass ich mir jetzt gleich ganz fürchterliche Schelte einhandeln werde. Aber zu der ganzen Sache mit dem RAM-Problem:

ich habe weder Ahnung [...] von Python selbst.

Die Antwort darauf lautet:

eine debugbare Hochsprache

Ich denke, dass grundsätzliche Problem besteht darin, dass der ganze Kram in Mono angegangen wurde und Mono einen dicken Haufen Resourcen verbraucht. Der Kram ist einfach nicht dafür geschrieben wurden, auf kleinen Maschienen (und bei virtuellen Containern reden wir von kleinen Maschienen) zu rennen. Das Zeugs lädt eine dicke VM nach, die a la Java anfängt sich an irgend nem Pseudo-Byte-Code tot zu rechnen. Zu allem Überfluss ist der Kram von Microsoft für Windows gebaut wurden, und Mono ist ein Versuch, das irgendwie auf Linux hinzubiegen. Im Ergebnis wird eine *.exe losgeballert, in einer Umgebung, die weder für soetwas gedacht, noch dafür optimiert wurde und die Folgen bekommen wir jetzt zu spüren.

Kann sein, dass es sich mit .NET schön coden lässt, aber für den hier angesetzten Einsatzzweck ist das meiner Meinung nach einfach das falsche Werkzeug. Ich weiß auch nicht, wie wir mit dieser Tatsache jetzt weiter umgehen wollen. Es gibt andere Sprachen wie etwa python, ruby, perl, ... in denen sich genauso schön Code schreiben lässt, die aber bei Weitem besser skalieren.

Nur meine Meinung, aber ich denke, der Ansatz, den wir gerade fahren ist der falsche und eine Sackgasse. Durch die Wahl der falschen Mittel ballern wir uns wieder und wieder den Server weg. So schwer es fällt (und ich weiß, dass da eine Menge wertvolle Arbeit drauf geht), ich denke, wir sollten uns das eingestehen und darüber nachdenken, wie wir die geschaffenen Lösungen auf eine solidere und bessere Grundlage stellen, die zu den Rahmenbedingungen passen, die uns gegeben sind. Und das heißt in meinen Augen: Portierung auf eine Scriptsprache wie python oder ruby.

[tox]

Den "dicken Haufen Ressourcen" von 20 bis 30 MB pro Instanz setze ich jetzt im Geiste mal in Relation zu den über 100 MB, die die Apache-Instanzen alle zusammen verbrauchen. Ich finde, der Speicherverbrauch von Mono steht in einem klar positiven Verhältnis zu dem, was man dann letzten Endes dafür bekommt. In einem Punkt muss ich dir widersprechen. Es gibt keinen Pseudocode. Es gibt einen gemeinsamen Zwischencode, der eine Art objektorientiertes Assembler darstellt, der vor der Ausführung in nativen Code kompiliert wird. Das ist grad der große Vorteil gegenüber Java, nämlich dass es im Vergleich zu dessen virtueller Maschine deutlich schneller ist. (Wiederum ein Ausgleich zu dem im Vergleich zu C-Programmen hohen Speicherverbrauch)

Wir haben jetzt genug Speicher und Speichermangel ist kein Problem mehr. Wenn überhaupt, sollten wir uns Gedanken über Graphviz machen, da belegt eine einzelne Instanz von Neato schon mal grob 100 MB bei der aktuellen Topogröße und png als Ausgabeformat.

Der Bug, dass sich der Datensammler ab und zu aufhing, geht zugegebenermaßen auf meine Kappe. Ich hatte die Beendigungsbedingungen für den Haupt-Thread bei der Parallelisierung (die ich auf Wunsch eines Einzelnen eingebaut hatte ) nicht ausreichend bedacht. Wurde jetzt behoben. Ich lass das jetz bis heute Abend noch schön ackern und wenn es dabei keine Fehler gibt (wovon ich ausgehe), mach ich den Cronjob wieder an.

@4huf den Kartenausschnitt schau ich mir noch mal an. Du hast Recht, dass man bei einem kleineren Fenster eher eine leere Mitte sieht. Ich hatte den Mittelpunkt so angepasst, dass das ZUW noch drauf ist bei meiner (zugegebenermaßen subjektiven) Bildschirmauflösung. Dann lass ich jetzt das ZUW bei der Zentrierung mal außen vor...

@tmk sieht das Layout in Safari einigermaßen fehlerfrei aus?

[3dfxatwork]

Als mit dem neuen wollten wir ja gerade weg von den Skriptsprachen, warum: Es ist schneller, und womöglich auch besser durchdacht, denn bei Skriptspachen wird schnell mal etwas geschrieben, was sich im nachhinein als nicht erweiterbar oder einfach nur langsam darstellt, und das nicht nur wegen der Skriptsprache an sich. Es gibt z.Z. einen Tenor, den man an manchen Stellen hört, dass man Skriptsprachen für eine schnellere Entwicklung einsetzt, und das massiv auf kosten der Geschwindigkeit, weil die Prozessoren ja so schnell sind.
Ich finde das nicht so toll und würde eine Hochsprache bei solchen sachen vorziehen.

@Papabaer Skriptsprachen skalieren schlechter als Hochsprachen

[PapaBaer]

Uh, vorsicht, das fängt an arg schwammig zu werden.

Hochsprache ist ja erstmal alles, was nicht Assembler heißt und hat mit der Tatsache, ob es compiliert, interpretiert oder als Byte-Code läuft nicht viel zu tun. Es ist daher auch mehr als gewagt zu behaupten, eine Skriptsprache an sich würde zu schlechterem Code führen. Ich würde dem widersprechen. Ich kann in jeder Sprache guten, erweiterbaren Code schreiben, oder Mist abliefern. Es ist nicht so, dass Sprachen, die compiliert werden irgend eine Vorraussetzung mitbrächten, per se saubereren Code abzuverlangen. Von daher gibt es keinen Grund, hier explizit Mono einsetzen zu wollen.

Zur Frage der Skalierung. Skalierung meint mehr, als reine Geschwindigkeit. Es stimmt, wenn 3dfx sagt interpretierte Sprachen laufen langsamer als compilierte Programme. Nur, wir reden gerade über die Frage des RAM-Verbrauches. Mir ist es total egal, wenn das ganze zwei Minuten länger braucht, dafür aber den Server nicht wegballert oder von uns verlangt, unmengen RAM in die VM zu zerren. Und: eure Argumentation trifft vielleicht auf C oder C++ zu, aber nicht auf Mono, da Mono nicht in Maschienencode compiliert wird.

Mir geht es um die Frage: Welches Werkzeug ist angebracht in der uns gegebenen Umgebung das beste Ergebnis zu liefern. Und wie ich schon begründet habe, scheint mir ein Werkzeug, dass von uns verlangt unmengen RAM in die Schlacht zu werfen, der falsche Weg. Da helfen auch keine Vergleiche, die anderen würden ja auch RAM verbrauchen. Stimmt, aber die erledigen ja auch andere (und viel größere) Aufgraben.

Wir wollen sicher in Zukunft noch das ein oder andere basteln. Ihr schreibt selbst: ein Argument für die Wahl des Werkzeuges ist, ob es erweiterbar ist. Wenn wir andauernd an RAM-Grenzen kommen ist es NICHT erweiterbar. Es gibt, für unseren Einsatzzweck, bessere Werkzeuge (weniger RAM, bessere Integration in Linux, lizenzrechtlich unbedenkliche Lösungen, Lösungen aus der Community, ...). Ich stelle einfach die Frage, ob die Entscheidung für das falsche Werkzeug aus persönlichen Preferenzen eine Sackgasse ist.

[Basti7]

Morgen Leute

hab seit 3 Tagen das Problem, ähnlich wie vor ein paar Monaten:

das seit ca. 4-5 Tagen Das Internet nichtmehr geht. Manchmal noch Früh am Morgen aber Tagsüber nur für ein paar Sekunden, dann aber wieder Minutenlang nix.

Mein Kumpel, welcher den Knoten (9.16 (WG_Heinrich-Thomas-Mann_Str_) gegenüber der Harzmensa betreibt, meint bei Ihm sei es genauso.
Damals schienen es die Spielhaus-Knoten zu sein

Hintergrund: Spielhaus 1 ist ausgefallen und Spielhaus 2 lenkt die gesamten Routen in seiner Umgebung ins Nirvana und damit kommt das halbe Paulusviertel und Univiertel nicht ins Internet.

Kann es daran liegen? Hat Jemand ähnliche Probleme?
Grüße,

Basti

[tmk]

Die 14.1 läuft aber. Ich vermute, es ist eher was an der 9.16 selber, die ist als gelber Pin verzeichnet gerade auf der Map. War die 14.1 direkter Nachbar der 9.16? Vielleicht ist die Antenne umgefallen? Oder probier mal Strom raus, kurz warten, Strom wieder rein. Klingt banal, hilft aber echt oft.