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?
Grüße, Kai
Zufällig hab ich mich damit heute mal beschäftigt, weil mir das Diagramm alles andere als einleuchtend war :)
Wenn man es in groß ansieht, dann erkennt man, dass die Tage in 6-Stunden-Segmente aufgeteilt sind, welche wiederum jeweils einen Balken pro Stunde haben. Die "halben" Nutzer sind demnach eine Krücke zur Darstellung der Nutzeranzahl innerhalb einer Stunde.
Bei mir ist es eine Einteilung von 0 bis 2, bei den ganz blumigen Knoten sicher auch mal 0 bis 40 (wenn es denn mal 40 in einer Stunde waren).
Am 17.06.2016 um 20:35 schrieb Kai Grünler:
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?
Grüße, Kai
Freifunk_info mailing list Freifunk_info@hateotu.de http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Also besonders sinnvoll finde ich diese 4-Stunden-Scheiben ja nicht. Kann man das wegmachen?
Ich fände es sinnvoller, wenn man als Balken die Gesamtnutzer pro Tag hätte und als Linie davor die Höchstnutzerzahl am Tag. Beispiel: Der Knoten hatte 50 Nutzer am Tag (Gesamtnutzer/Balken dahinter) und max. 15 Nutzer gleichzeitig (Höchstnutzerzahl/Linie davor).
Grüße,
Kai
Am 17.06.16 um 21:25 schrieb Michael Gutmann:
Zufällig hab ich mich damit heute mal beschäftigt, weil mir das Diagramm alles andere als einleuchtend war :)
Wenn man es in groß ansieht, dann erkennt man, dass die Tage in 6-Stunden-Segmente aufgeteilt sind, welche wiederum jeweils einen Balken pro Stunde haben. Die "halben" Nutzer sind demnach eine Krücke zur Darstellung der Nutzeranzahl innerhalb einer Stunde.
Bei mir ist es eine Einteilung von 0 bis 2, bei den ganz blumigen Knoten sicher auch mal 0 bis 40 (wenn es denn mal 40 in einer Stunde waren).
Am 17.06.2016 um 20:35 schrieb Kai Grünler:
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?
Grüße, Kai
Freifunk_info mailing list Freifunk_info@hateotu.de http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Freifunk_info mailing list Freifunk_info@hateotu.de http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
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/
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/
On Fri, 17 Jun 2016 21:34:16 +0200 Sven Eckelmann sven@narfation.org wrote:
Das ganze funktioniert ueber RRD [1]. Dadurch kann man Statistiken ueber laengere Zeit machen und begrenzt trotzdem die Groesse der Datenbank enorm.
RRD-Graphen find ich jetzt nicht besonders spannend - seh ich aber auch auf Arbeit jeden Tag ;)
Die up/down-Eigenschaft hinter die Anzahl der Clients zu legen find ich aber nicht besonders clever - der Graph enthält jetzt keine down-Periode, aber ich hab auch keinen Graphen gefunden, der mit widerspricht - man kann dann nicht am Graphen unterscheiden, ob einfach keine Clients angemeldet waren oder der AP sich nicht gemeldet hat. Weil der dann eigentlich rot zu malende Hintergrund nur die Fläche von der Nulllinie bis zur Nulllinie einnimmt :)
Man koennte natuerlich statt dem Durschnitt auch mit dem Maximum rechnen. Das funktioniert aber nur wenn man eine komplett neue Datenbank erstellt und pflegt.
Können wir ja selbst machen. Wir haben sicherlich auch genug Speicherplatz, um 5-Min-Genauigkeit (oder eben so granular, wie die APs es melden, wenn sie nicht aktiv gefragt werden sollten) über Monate zu speichern, was das vielleicht etwas übersichtlicher macht.
Carsten
Doch, das ist erkennbar. Downtime wird flächenfüllend über den Zeitraum rot dargestellt.
Ohne Clients, aber online, ist es komplett weiß.
Am 17.06.2016 um 22:08 schrieb Carsten Weber:
On Fri, 17 Jun 2016 21:34:16 +0200 Sven Eckelmann sven@narfation.org wrote:
Das ganze funktioniert ueber RRD [1]. Dadurch kann man Statistiken ueber laengere Zeit machen und begrenzt trotzdem die Groesse der Datenbank enorm.
RRD-Graphen find ich jetzt nicht besonders spannend - seh ich aber auch auf Arbeit jeden Tag ;)
Die up/down-Eigenschaft hinter die Anzahl der Clients zu legen find ich aber nicht besonders clever - der Graph enthält jetzt keine down-Periode, aber ich hab auch keinen Graphen gefunden, der mit widerspricht - man kann dann nicht am Graphen unterscheiden, ob einfach keine Clients angemeldet waren oder der AP sich nicht gemeldet hat. Weil der dann eigentlich rot zu malende Hintergrund nur die Fläche von der Nulllinie bis zur Nulllinie einnimmt :)
Man koennte natuerlich statt dem Durschnitt auch mit dem Maximum rechnen. Das funktioniert aber nur wenn man eine komplett neue Datenbank erstellt und pflegt.
Können wir ja selbst machen. Wir haben sicherlich auch genug Speicherplatz, um 5-Min-Genauigkeit (oder eben so granular, wie die APs es melden, wenn sie nicht aktiv gefragt werden sollten) über Monate zu speichern, was das vielleicht etwas übersichtlicher macht.
Carsten
Freifunk_info mailing list Freifunk_info@hateotu.de http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Verdammt ... als ich mich heute Nachmittag damit beschäftigt hatte, war das noch so. Jetzt muss ich dir recht geben, Carsten :/
Scheint wohl ein Bug zu sein?
Am 17.06.2016 um 22:16 schrieb Michael Gutmann:
Doch, das ist erkennbar. Downtime wird flächenfüllend über den Zeitraum rot dargestellt.
Ohne Clients, aber online, ist es komplett weiß.
Am 17.06.2016 um 22:08 schrieb Carsten Weber:
On Fri, 17 Jun 2016 21:34:16 +0200 Sven Eckelmann sven@narfation.org wrote:
Das ganze funktioniert ueber RRD [1]. Dadurch kann man Statistiken ueber laengere Zeit machen und begrenzt trotzdem die Groesse der Datenbank enorm.
RRD-Graphen find ich jetzt nicht besonders spannend - seh ich aber auch auf Arbeit jeden Tag ;)
Die up/down-Eigenschaft hinter die Anzahl der Clients zu legen find ich aber nicht besonders clever - der Graph enthält jetzt keine down-Periode, aber ich hab auch keinen Graphen gefunden, der mit widerspricht - man kann dann nicht am Graphen unterscheiden, ob einfach keine Clients angemeldet waren oder der AP sich nicht gemeldet hat. Weil der dann eigentlich rot zu malende Hintergrund nur die Fläche von der Nulllinie bis zur Nulllinie einnimmt :)
Man koennte natuerlich statt dem Durschnitt auch mit dem Maximum rechnen. Das funktioniert aber nur wenn man eine komplett neue Datenbank erstellt und pflegt.
Können wir ja selbst machen. Wir haben sicherlich auch genug Speicherplatz, um 5-Min-Genauigkeit (oder eben so granular, wie die APs es melden, wenn sie nicht aktiv gefragt werden sollten) über Monate zu speichern, was das vielleicht etwas übersichtlicher macht.
Carsten
Freifunk_info mailing list Freifunk_info@hateotu.de http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Freifunk_info mailing list Freifunk_info@hateotu.de http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
On Fri, 17 Jun 2016 22:16:14 +0200 Michael Gutmann hateotu.burns@area.ovh wrote:
Doch, das ist erkennbar. Downtime wird flächenfüllend über den Zeitraum rot dargestellt.
Ohne Clients, aber online, ist es komplett weiß.
Hab mir extra paar von den als "offline" bei den Chemnitzern angezeigten Knoten angeschaut. Da ist der Hintergrund bei allen weiß gewesen - siehe z.B. "C-WOerttel59Innenhof" - offline seit 18 Tagen, und der komplette Graph ist weiß.
Carsten
Mittlerweile scheint es wieder erkennbar zu sein. Sogar die "halben" Clients sind weg :)
Am 17.06.2016 um 22:30 schrieb Carsten Weber:
On Fri, 17 Jun 2016 22:16:14 +0200 Michael Gutmann hateotu.burns@area.ovh wrote:
Doch, das ist erkennbar. Downtime wird flächenfüllend über den Zeitraum rot dargestellt.
Ohne Clients, aber online, ist es komplett weiß.
Hab mir extra paar von den als "offline" bei den Chemnitzern angezeigten Knoten angeschaut. Da ist der Hintergrund bei allen weiß gewesen - siehe z.B. "C-WOerttel59Innenhof" - offline seit 18 Tagen, und der komplette Graph ist weiß.
Carsten
Freifunk_info mailing list Freifunk_info@hateotu.de http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info
Hi,
Sven hat die Sache mal an die Upstream Entwickler herangetragen und auch schon unsere Graphen verbessert. Falls Ihr moechtet koennt Ihr gern in dem github issue hier mitdiskutieren:
https://github.com/ffnord/ffmap-backend/issues/85
Viele Gruesse, Simon
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?
Grüße, Kai
-
Carsten Weber -
Kai Grünler -
Michael Gutmann -
Simon Wunderlich -
Sven Eckelmann