[quote=„maz, post:24, topic:10570“]
Die erhöhte Last auf den Supernodes auch?
[/quote] ja, wir haben in Freiburg recht leistungsstarke Maschinen, es scheint, das stecken die locker weg.
das müsstest du belegen, in einem anderen Thread ist das schonmal lang lang lang nicht passiert. der Unterschied „unverschlüsselt-fastd-limit=1“ und l2tp scheint faktisch nicht/kaum zu existieren. Alles andere müsstest du mir erklären - bzw ich empfehle die Doku zu fastd
Stichwort Kontextswitche, viel mehr braucht man dazu nicht zu sagen.
Kontextswitche sind aber orthogonal zur Verschlüsselung: Du kannst im Kernel IPSec verschlüsseltes L2TP machen (Datenweiterleitung ohne Kontextswitch) und im Userspace fastd ohne Verschlüsselung (mit Kontextswitch)
Das war doch genau meine Aussage, dass nicht die Verschlüsselung das Problem ist, sondern Fastd.
Das war mir nicht klar. Und ich vermute, dass auch hier nicht allen Mitlesenden klar ist, dass ein Großteil des Performancegewinns keineswegs durch die fehlende Verschlüsselung erreicht wird.
Der Fastd ohne Verschlüsselung bringt ein paar MBit/s mehr auf den Plasterouter, auf den Supernodes ändert sich nix. Was an CPU-Zeit durch die fehlende Verschlüsselung eingespart wird, frißt die Zunahme von Kontextswitche durch mehr Traffic wieder auf.
So ganz stimmen die Stats aktuell nicht, wir sind ein wenig um Umbau der Supernodes. Beim Traffic und bei den Kontextwechseln fehlt Node03.
Clientnetz ist noch Fastd, Backbone-Anbindung und Vernetzung untereinander ist bereits L2TP.
@dgoersch ; du gibst dir nicht gerade mühe mit deinen kurzsilbigen Antworten das ich dich verstehe. Kontextswitch hab ich bis gerade eben noch nie was von gehört.
und dann zu sagen: ey - fastd doof … ja weil halt … kontextswitch, mehr brauch ich nicht zu sagen !
tschuldige , das verbuch ich unter frustige Antwort und im Lesefluss des Forums auch eher mies. (no offence)
zumind. hier im Forum 2 Einträge gefunden : was auch nicht sonderlich viel ist, von denen auch nur der erste wirklich von Kontextswitchen handelt - dafür aber ganz brauchbar ist.
zu der Bandbreitenfrage, klar reichen ±10Mbit am Router in der Regel aus für alles was man so macht, bleiben aber trotzdem nur ±10 Mbit. Die Anbindung hintendran ist dann der „nächste“ Hals - und vermutlich für die meisten in großen netzen, der Reale Flaschenhals.
Interessant, dass du mir dann die Doku nahe legen willst…
Erfahrungsgemäß ist Bandbreite weder bei Supernodes noch im Backbone ein limitierender Faktor, da wird entsprechend expandiert - zumindest im FFRLeV. Die Supernodes sind, dank der Kontextswitche durch Fastd, CPU-mäßig ziemlich am Limit. Das ändert sich mit L2TP schlagartig und so massiv, dass eben trotz „verlorener“ Verschlüsselung die Kosten-/Nutzenrechnung für L2TP spricht.
@dgoersch : du tust gerade so weiter, in der fastd Doku kommt Kontext switching als Begriff zum Bsp. nicht vor. Ansonsten hab ich darin viel gelesen und dort Verständnisfragen gestellt.
Aber ich will gerne dazu lernen, daher konkrete Fragen …
(nach upgrades haben wir hier zum Beispiel keine/kaum am limit fahrende CPUs mehr)
Prinzipiell betrifft es beide Seiten. Ein typischer Plasterouter macht mit L2TP auch mal problemlos 80Mbit/s oder mehr. Hier sehe ich persönlich aber nicht unbedingt die Notwendigkeit, da irgendwann eben auch der Uplink zum Supernode (sprich der Internetanschluss des Aufstellers) zum Flaschenhals wird.
Auf den Supernodes hingegen wird massig CPU-Zeit dadurch verbraten.
Kontextswitche kosten CPU-Zeit, also Load/CPU-Auslastung. Problematisch wird es, wenn deine CPU am Anschlag ist, aber noch Bandbreite vorhanden wäre. Man kann dem natürlich mit „more Power“ entgegenwirken, aber irgendwann kann man das halt nicht mehr sinnvoll rechtfertigen, für ein paar Mbit/s Traffic, mehrere GHz Taktrate (und damit natürlich auch Energie) zu verbraten.
L2TP läuft im Kernelspace und damit gibt es keine Kontextswitche und kein irrsinniges Verbraten von CPU-zeit. Soweit ich weiß, gibt es bislang allerdings keine Verschlüsselung für L2TP, die auf den Plasteroutern einsetzbar wäre - auf den Supernodes könnte das IPSec sein.
Wenn ihr keine CPUs am Limit habt, darf ich fragen, wie viele Nodes und Clients ihr mit wie vielen Supernodes bedient?
Unsere Load ist aktuell auch im Mittel deutlich unter 1, wir haben zu Spitzenzeiten aber auch immer wieder Peaks um die 1,5 (bei zwei Kernen).
Ich glaube ein paar Diskussionsteilnehmern ist nicht klar, was ein Kontextwechsel ist.
Es gibt unter Linux den Kernel- und den Userspace. Code der im Kernel läuft, wird keiner großen Rechteprüfung unterzogen und einfach ausgeführt. Das ist extrem schnell, aber wenn es etwas passiert, was nicht passieren sollte, stürzt die Maschine mit einer Kernelpanik ab. Im Userspace gibt es eine Art Schutzmechanimus, der z.B. verhindert, dass ein Prozess auf falsche Speicherbereiche zugreift. Diese Absicherung und somit der Wechsel, das nennt man Kontextwechsel. Und das kostet Zeit. Fastd macht das pro jedem einzelnen Paket.
Es ist nicht nur die Geschwindigkeit alleine die mit L2TP steigt, man verliert weniger Pakete und die Latenz ist etwas niedriger. Das sind zwei Faktoren, die das Surfgefühl verbessern.
Die CPU-Load die bei fastd anfällt ist zu 90% diese beschriebe Rechteverwaltung. Daher schafft ein 841er dann plötzlich nicht mehr nur 8 Mbit/s sondern > 60 Mbit/s.
Ich hoffe es ist grob klar, vermutlich kann es jemand anders noch etwas besser erklären.
Grüße
Matthias
In dem Artikel geht es zwar um Multitasking, aber wenn man sich klar macht, dass der Hauptoverhead beim Multitasking daran liegt, den aktuellen Status des laufenden Programms vom Prozessor in den Speicher zu sichern und wiederherzustellen, und das bei jedem Wechsel in den Kernel passiert (egal ob Timerinterrupt oder Syscall), dann wird klar dass es ähnlich ist.
Hier sehe ich persönlich aber nicht unbedingt die Notwendigkeit, da irgendwann eben auch der Uplink zum Supernode (sprich der Internetanschluss des Aufstellers) zum Flaschenhals wird.
Wie man’s nimmt. Bei einigen entspricht 80 Mbit/s gerade einmal 20% der gebuchten Anbindung (Unitymedia Ftw 
) Aber klar, die Supernodes sind wohl langfristig wichtiger zum Skalieren. Context switching finde ich jetzt auch selbsterklärend bzw. das ist so wichtig für die Performance das man es sofort Googeln sollte wenn nicht bekannt.
Sobald größere Menschengruppen (aktuell z.B. die Flüchtlingsunterkünfte) Freifunk nutzen ist jedes zusätzlich Mbit IMHO Gold wert. Klar, auf Seite der Gruppe kann man x86 Offloader einsetzen.
