HopGlass - Development Thread

@PetaByteBoy http://148.251.208.172/hopglass/
Ist die aktuelle Version von Github.

In Aachen haben wir das selbe Problem.

Ich habe mal in meiner Not angefangen eine stark vereinfachte Karte mit aktuellem Leaflet zu implementieren, damit wir wieder was „DAU-freundliches“ haben. (Manche Leute meckern, dass die Karte ja kaputt sei, weil sie einfach nicht die ~15 Sekunden Renderzeit abwarten)

Aktueller Stand: http://tiles.yayachiken.net/ffac-map/
Source: GitHub - ffac/basic-nodemap

Während der Implementierung ist mir aufgefallen, dass die Karte dann enorm viel Performance verliert, sobald man einstellt, dass die Labels mit dem Namen permanent angezeigt werden. Das aktuelle Leaflet ermöglicht, diese Labels nur beim Drüberfahren mit dem Mauszeiger anzuzeigen. Dabei verringert sich die Ladezeit massiv. Ich vermute, dass es eben am Rendering liegt. Bei den Punkten für die Clients wäre es dann vermutlich ähnlich.

Es würde sich also imo mal lohne zu testen, ob das Deaktivieren des Zeichnens der Labels, der Clientpunkte oder beiden eine Verbesserung bei vielen Knoten bringt. Wenn ja, dann habe ich die Befürchtung, dass Leaflet in der aktuellen Forum für so viel Client-Side-Rendering einfach nicht geeignet ist.

ja clients ziehen auch viel performance hatte damals mal mit der aliases.json rumgespielt und bei mehreren Tausend clients auf einem AP lagged es gewaltig :wink:

there could be a path in

  • not rendering labels and clients in low zoomlevels
  • and zoomed in just loading bounding boxes of Nodes.

But off course, this would require some geo-db magic in Hoppglas server.

Gibt es dazu irgendetwas wie eine Doku, dass sich Außenstehende da einarbeiten können?

bekomme grade beim bauen:

Running "git-describe:default" (git-describe) task
Warning: fatal: Not a git repository (or any of the parent directories): .git Use --force to continue.

Aborted due to warnings.

hatte das jemand schon mal ?

Bist du im richtigen Verzeichnis?

Du musst den Ordner via Git pullen, nicht als Zip-Datei herunterladen.
Es wird versucht die git revision beim bauen abzufragen, was bei einem normalen Ordner natürlich nicht klappt.

1 „Gefällt mir“

ah ok ja hatte den Ordner als zip geladen da ich kurz mal was testen wollte → Bildungslücke geschlossen :smiley:

Falls ihr einen Hack habt, um die vom respondd (2016.2.2 und älter) als „other“ reporteten vlan-Links (auch Wifi) als Radiolinks gezeichnet zu bekommen (und nicht als „wired“), Milan freut sich sicher über einen PR.

Oh das ist mir auch schon aufgefallen. Dachte es wäre ein Bug mit doppelten Datensätzen.
Schwer zu sagen warum diese unter Other aufgeführt werden, eigentlich sollten diese dann unter Wifi landen…
Bin mir nicht mal sicher ob man das auf der Hopglass Seite ändern kann, schau ich mir aber gerne mal an. Javascript ist leider nicht so mein Favorit, aber für patching sollte es reichen.

Hatten wir da oben schonmal.

Da ist der Fix: (3.Dezember 2016, daher noch nicht im 2016.2.2)

Müsste man sich für einen Stable-Build also ggf. cherrypicken.

Hey @collimas, schon weiter gekommen? Hab das gleiche Problem. Hab mich die letzten Tage selbst durch gewurschtelt. Hast du fastd und batman-adv schon am laufen?

Wo werden denn die „zuletzt gesehen“-Werte usw. gespeichert?

@ulix: Bisher noch keine Zeit gehabt. Ich hoffe, dass ich am Wochenende dazu komme.

Da:

(d.lastseen)
wird dann mit moment.js umformatiert ausgegeben.

Habe eure Daten mal genommen und etwas experimentiert:

In der forcegraph ist tatsächlich noch ein bug/feature :wink:
Aktuell werden die clients egal bei welcher Zoomstufe gezeichnet :frowning:

das

if (scale >0.9)

sollte eure Karte drastisch beschleunigen :wink: (ungefähr Zeile 379)

// -- draw clients --
  ctx.save()
  ctx.beginPath()
  if (scale > 0.9)
    nodes.filter(visibleNodes).forEach(function (d) {
      var clients = d.o.node.statistics.clients
      if (clients === 0)
        return

      var startDistance = 16
      var radius = 3
2 „Gefällt mir“

Naja so viel besser ist die Performance damit auch nicht. Wir müssen mal einen ordentlichen performance profiler drüberlaufen lassen und sehen was die meiste Zeit braucht.

Neuer PR für Hopglass-Server:

Das Gateway-Label ist an dieser Stelle falsch und sollte eine eigene Metrik sein.
Label dürfen laut Doku nicht für Werte mit hoher Kardinalität oder für uneingeschränkte Datensätze verwendet werden.

CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

Da ich grade am fixen und aufräumen der alisases.json war:

Habe da auch mal Erläuterungen dazu gepackt (Ist noch nicht ganz Vollständig / Habe aber grade keine Lust das weiter zu tippen :stuck_out_tongue: )

2 „Gefällt mir“

Da wir immer wieder merken wie unzuverlässig UDP im Mesh ist, habe ich einen neuen Aflred Receiver für Hopglass geschrieben. Zwar nutzt Alfred auch UDP aber es verwendet zusätzlich Transaktionen welche zuverlässiger beim übertragen der Daten sind.
Momentan benötigt dieser noch die Alfred-json Binary um die Daten abzufragen, aber ich arbeite daran den eigenen Client aus dem veralteten Alfred Branch zu portieren.

Einfach den Announced-Receiver aus der config.json entfernen und den Alfred-Receiver anhand der config.json.example entsprechend konfigurieren.

1 „Gefällt mir“