Sorry, wenn ich jetzt folgendes schreibe: HÄH??? Ägypten???
Meinen Vorschlag hatte ich mit anderer Mail schon zum besten gegeben. Wenn das so kompliziert ist, wie es klingt, schau ich mir das Diagramm einfach nimmer an und kann halt keine sinnvolle Auswertungen für Argumentationen erstellen. Ich werd es überleben.
Kai
Am 17.06.16 um 21:34 schrieb Sven Eckelmann:
On Friday 17 June 2016 20:35:08 Kai Grünler wrote:
Hallo zusammen,
kurze Verständnisfrage: Im Meshviewer gibt es unten ein Diagramm wie zB https://meshviewer.chemnitz.freifunk.net/nodes/f4f26dc1f94e.png Die Y-Skala hat Werte von 0,0 bis 6,0. Bedeutet das, hier waren halbe Nutzer (?) online wenn ,5 hinten dran steht? Und max. 6 Nutzer werden gleichzeitig erfasst?! Ich hatte früher so 5..40 Nutzer online, jetzt zeigt die Skala 3,5 oder sowas an. Oder deute ich das Diagramm verkehrt? Kann man das so konfigurieren, dass es wieder reale Zahlen anzeigen kann?
Das ganze funktioniert ueber RRD [1]. Dadurch kann man Statistiken ueber laengere Zeit machen und begrenzt trotzdem die Groesse der Datenbank enorm. Das hat natuerlich auch Nebeneffekte - einen davon siehst du gerade mit dem Durchschnitt der Clients ueber eine bestimmte Zeiteinheit [2].
Du siehst also keine besonders kleinen Clients, die nur als .5 gezaehlt werden, sondern das im Durchschnitt ueber eine bestimmte Zeiteinheit x.5 Clients da waren. Also zum Beispiel waren in der ersten Haelfte der Zeiteinheit 4 Client online und bei der zweiten Haelfte der Zeiteinheit 5 Clients online. Wenn RRD sein Datencrunching durchfuehrt und ueber die Dateneingaben seine Durchschnitte bildet, dann kommt 4.5 Clients fuer diesen Zeitabschnitt raus.
Man koennte natuerlich statt dem Durschnitt auch mit dem Maximum rechnen. Das funktioniert aber nur wenn man eine komplett neue Datenbank erstellt und pflegt.
Das Limit der y-Achse wird automatisch nach dem Maximum der gezeichneten Durchschnitte gewaehlt. Wenn du also also keinen Zeitabschnitt hast bei dem mehr als 5.5 Clients im Durschnitt erkannt wurden, muss die Skala auch nicht ueber 6.0 hinausgehen.
Leider weiss ich nicht genau was du mit "reale Zahlen" meinst. Mathematisch gesehen sind das "reelle Zahlen" (nur zwei Buchstaben entfernt :D) - aber das meinst du sicher nicht. Vielleicht meinst du mit "reale Zahlen" die Zahlen, die deine Node gemessen hat. Vielleicht sollten wir also erstmal klaeren was die Node misst und was sie meldet.
Also batman-adv hat einen Translation-Table (also FIB). Dieser ist unterteilt in einen globalen und einen lokalen Anteil. Der lokale Anteil wird mit anderen Nodes synchronisiert um Teil des globale Translation-Table dieser anderen Nodes zu werden. Dadurch wissen sie global wohin Daten fuer einen Client geroutet werden muessen. Also ist der lokale Translation- Table der Anteil an Client-Adressen, die lokal erkannt wurden und nicht geroutet werden muessen. An den Server (der die Daten fuer RRD sammelt) wird nun regelmaessig die Anzahl der Eintraege im lokalen Translation-Table einer Node gemeldet, die nicht Multicast-Adressen und nicht von AP selber sind. Dies sind also ganze, positive Zahlen (N0) und entsprechen den momentan geclaimten Adressen der Clients an WLAN oder LAN. Daher wuerde ich behaupten, dass diese Zahlen "real" sind. Das ist schon daher so zu sehen, da diese Menge an Adressen zum Zeitpunkt der Messung fuer reale Routing- Entscheidungen genutzt werden.
Also werden reale Zahlen an den Server gemeldet und der sammelt ueber Zeitabschnitte diese Daten um Durchschnitte zu speichern und zu zeichnen.
Wenn du irgendwelche speziellen Verbesserungsvorschlaege dafuer hast, dann meldest du sie am besten an das Upstream-Projekt. Diese haben mehr Detailwissen darueber und koennen diese daher auch besser ausdiskutieren und umsetzen.
Gruesse, Sven
[1] http://oss.oetiker.ch/rrdtool/ [2] https://github.com/ffnord/ffmap-backend/blob/c74b7b95fb5d65dcf0fee7eb5a5525a... [3] https://github.com/ffnord/ffmap-backend/