Arbeitsgruppe Software Failure Monitoring: Unterschied zwischen den Versionen
Markit (Diskussion | Beiträge) |
Markit (Diskussion | Beiträge) |
||
| Zeile 1: | Zeile 1: | ||
| − | Momentan gibts zwar Smokeping | + | Momentan gibts zwar Smokeping, aber ausser dem IRC-Bot keine allgemeinen Netz-Qualitäts-Monitoring Tools |
Ideen: | Ideen: | ||
| Zeile 7: | Zeile 7: | ||
oder peridisch die bandbreite aller knoten testen [Arbeitsgruppe_Software_PINGPERF|PING-Performance], und die gesamt/durchschnitts werte verwenden | oder peridisch 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 ... (-;) | ||
Version vom 7. August 2008, 22:24 Uhr
Momentan gibts zwar Smokeping, aber ausser dem IRC-Bot keine allgemeinen Netz-Qualitäts-Monitoring Tools
Ideen:
Man könnte den gesamt smokeping, grafisch darstellen
oder peridisch 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 ... (-;)
