Arbeitsgruppe Software Failure Monitoring: Unterschied zwischen den Versionen
Markit (Diskussion | Beiträge) |
Markit (Diskussion | Beiträge) |
||
| (4 dazwischenliegende Versionen von einem Benutzer werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | Momentan gibts zwar Smokeping | + | Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: Markus Kitttenberger) |
| + | ---- | ||
| + | Momentan gibts zwar Smokeping, aber (ausser dem node-count vom IRC-Bot) keine allgemeinen/übersichtlichen Netz-Qualitäts-Monitoring Tools | ||
Ideen: | Ideen: | ||
| − | Man könnte den gesamt smokeping, grafisch darstellen | + | Man könnte den gesamt/druchschnitts smokeping aller knoten, grafisch darstellen |
| − | oder | + | oder periodisch die bandbreite aller knoten testen [Arbeitsgruppe_Software_PINGPERF|PING-Performance], und die gesamt/durchschnitts werte verwenden |
| − | Weiters wär natürlich ein Mail oder gar SMS an bestimmte leute in bestimmten Fällen ganz hilfreich,.. | + | Bei beiden bedarf es aber auch eine Auswahl an wichtigen Knoten (evt. manuell oder über ihre durchschnittlcihe bandbreite und Anzahl der der über sie gerouteten Knoten) um so auch durchscnittswerte eines "funknetz" backbones liefern zu können |
| + | |||
| + | Weiters wär natürlich ein Mail oder gar SMS an bestimmte leute in bestimmten Fällen (backbone qualitiy drop) ganz hilfreich,.. | ||
Ein weitere Anwendungsfall von nem guten quality benchmark ist das switchen des freenet-gateways am subway,.. | Ein weitere Anwendungsfall von nem guten quality benchmark ist das switchen des freenet-gateways am subway,.. | ||
| − | (welcher momentan automatisch auf den tunnelserver switcht wenn der roofnode komplett tot ist) Aber ein bißchen früher würde sinn machen, vorallem wenn keine olsr-conectivity zwischen roofnode und tunnelserver mehr besteht, und der roofnode kaum noch | + | (welcher momentan automatisch auf den tunnelserver switcht wenn der roofnode komplett tot ist) |
| + | |||
| + | Aber ein bißchen früher würde sinn machen, vorallem wenn keine olsr-conectivity zwischen roofnode und tunnelserver mehr besteht, und der roofnode kaum noch Nachbarn hat,.. (d.h. der tunnelserver bereits besser ist) | ||
| + | |||
| + | Ausserdem wäre ein zusätzlicher externer Smokeping (evt. mit niedrigeren testintervallen) ganz hilfreich, um mal zusehen wie oft die default routen im netz nicht hinhauen, denn der marvin testet im grunde nur die connectivity zwischen housing (dessen HNA Announcement) und dem Freenet (in der Theorie sollten keine unterschiede zwischen dem 0.0.0.0 announcement und dem housing announcement im netz auftauchen, aber ... (-;) | ||
Aktuelle Version vom 7. August 2008, 22:54 Uhr
Achtung dies ist ein WoW (Maintainer: Markus Kitttenberger)
Momentan gibts zwar Smokeping, aber (ausser dem node-count vom IRC-Bot) keine allgemeinen/übersichtlichen Netz-Qualitäts-Monitoring Tools
Ideen:
Man könnte den gesamt/druchschnitts smokeping aller knoten, grafisch darstellen
oder periodisch die bandbreite aller knoten testen [Arbeitsgruppe_Software_PINGPERF|PING-Performance], und die gesamt/durchschnitts werte verwenden
Bei beiden bedarf es aber auch eine Auswahl an wichtigen Knoten (evt. manuell oder über ihre durchschnittlcihe bandbreite und Anzahl der der über sie gerouteten Knoten) um so auch durchscnittswerte eines "funknetz" backbones liefern zu können
Weiters wär natürlich ein Mail oder gar SMS an bestimmte leute in bestimmten Fällen (backbone qualitiy drop) ganz hilfreich,..
Ein weitere Anwendungsfall von nem guten quality benchmark ist das switchen des freenet-gateways am subway,.. (welcher momentan automatisch auf den tunnelserver switcht wenn der roofnode komplett tot ist)
Aber ein bißchen früher würde sinn machen, vorallem wenn keine olsr-conectivity zwischen roofnode und tunnelserver mehr besteht, und der roofnode kaum noch Nachbarn hat,.. (d.h. der tunnelserver bereits besser ist)
Ausserdem wäre ein zusätzlicher externer Smokeping (evt. mit niedrigeren testintervallen) ganz hilfreich, um mal zusehen wie oft die default routen im netz nicht hinhauen, denn der marvin testet im grunde nur die connectivity zwischen housing (dessen HNA Announcement) und dem Freenet (in der Theorie sollten keine unterschiede zwischen dem 0.0.0.0 announcement und dem housing announcement im netz auftauchen, aber ... (-;)
