> Ich könnte mir vorstellen, dass die CPU einfach nicht mehr hinterher > kommt, sprich das keine Zeit mehr für batman-adv bleibt, alle an das > batman-interface (normalerweise bat0, auf den Gateways bat-ffhh) > gesendeten Pakete rechtzeitig zu verarbeiten. Vielleicht kann man das > irgendwie mit der CPU-Last korrelieren?
Ja, die Vermutung, dass die kleineren Plaste-Router CPU-bound Pakete droppen und dadurch Retransmits verursachen, war der ursprüngliche Grund, wieso ich mich für die nodes.json interessiert habe. Verblüffenderweise ist der TX-Loss anscheinend nicht Hardware-abhängig... Bei Gateways ohne TX-Queue kann ich mir auch gut vorstellen, dass die bei CPU- und Net-IO-Lastspitzen Pakete verwerfen. Ich nehme an, dass der Verzicht auf eine TX-Queue geringfügig mehr Durchsatz bei geringfügig weniger Latenz bringt und die Queue deswegen wegkonfiguriert wurde. Bei den Gateways gibt es deutliche Unterschiede zwischen FFNord (mindestens 2 Promille TX-Drop) und FFHH (nur ein GW hat überhaupt TX-Drop). Könnte der Drop im Promille-Bereich, wenn er aus zeitweise höheren Dropraten in Spitzenzeiten herrührt, teilweise die, Gerüchten zufolge, wahrgenommenen Qualitäts-Defizite im FFNord-Netz erklären? -- Allan Wegan <http://www.allanwegan.de/> Jabber: [email protected] OTR-Fingerprint: E4DCAA40 4859428E B3912896 F2498604 8CAA126F Jabber: [email protected] OTR-Fingerprint: A1AAA1B9 C067F988 4A424D33 98343469 29164587 ICQ: 209459114 OTR-Fingerprint: 71DE5B5E 67D6D758 A93BF1CE 7DA06625 205AC6EC
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Freifunk mailing list [email protected] https://www.hamburg.ccc.de/mailman/listinfo/freifunk
