Okay, da habe ich mich mit den aktuellen großen CPUs wohl etwas verschätzt, auf bis zu 160 Mbit/sek kann man offensichtlich kommen. Schau dir einmal an wie es selbst bei der Nutzung mehrer CPUs durch Tricks aussieht: Um wegen diesem Problem mehrere CPUs nutzen zu können hat einer mehrere paralelle Tunnel gemacht. Und er hat die gleichen Probleme, über 160Mbit/sek pro CPU kommt er nicht: https://forums.openvpn.net/topic8723.html
Ich bin beim MultipathVPN bei 80 Mbit/sek hängen geblieben, und da ist mein Userspaceantzeil bereits bei etwas unter 50 % auf einem Intel I5 @3,6 Ghz, mit 100 Mbit/sek war ich wohl trotzdem etwas zu pessimistisch. Der fastd, und vermutlich auch openVPN, sind bei unter 20%, darum ist dann natürlich noch etwas mehr für den Kontextwechsel übrig. Beim OpenVPN ist die Grenze laut besagtem Post bei 160 Mbit/sek zu finden. Und natürlich haben diese Probleme auch andere, findet man im Google recht einfach.
Weitere Links mit gleichem Tenor:
MTU erhöhen kann beidseitig lokale (!) tcpverbindungen beschleunigen (klar, dann gibts es pro read/write mehr Daten): http://comments.gmane.org/gmane.network.openvpn.user/32043
Ubiquity systeme: CPU limitiert auf 12 Mbit/sek: http://community.ubnt.com/t5/EdgeMAX/OpenVPN-Performance-Throughput/td-p/567901
…
Es gibt sogar ein ausführliches Paper dazu, das auch auf die „magische“ Wirkung der MTU erhöhung kommt: https://staff.science.uva.nl/c.t.a.m.delaat/rp/2010-2011/p09/report.pdf Diese hilft allerdings beim Forwarden nicht, da die Pakete ja in 1500er Einheiten übers Netzwerk geliefert werden. Mit AES-128-CBC Verschlüsselung liegen die auch nur bei etwa 160 Mbit/sek, siehe Seite 28.
Auf Seite 35 kann man sogar genau euren Anwendungsfall sehen, und hier kommt er nur noch auf unter 120 Mbit/sek. Man sieht auch schön dass diese MTU erhöhung beim Routen nichts bringt, und dass es einen Unterschied macht ob man die Daten geroutet überträgt oder ob diese von lokal kommen. Und warum die MTU Erhöhung nichts bringen kann erklärt er auch.
[quote]CONCLUSION
…
Many different parameters can be used on the first lab setup. In particular the OpenVPN fragmentation options and TUN MTU size.
…
Even though we were unable to exactly pinpoint the exact cause of the
performance loss, we came to interesting results showing differences in performance
loss using different encryption and hashing algorithms. The proposed
future work supplies for enough interesting studies
…[/quote]
Schade, auf die Ursache dafür ist er nicht gekommen.
Die ganzen Werte habe natürlich nur indirekte Relevanz bei den kleinen Kisten mit ARM Prozessor, der teilweise recht anders arbeitet. Wie es läuft mit nur einer CPU, die auch noch ARM ist, sowie wesentlich langsamer taktet, sieht das ganze natürlich entsprechend schlechter aus. Und das wisst Ihr ja schon, deswegen habt Ihr ja diesen Thread begonnen.
Ich hab auf meinen Alixsystemen übrigends mit L2TP im Vergleich zu OpenVPN auch nur etwa 300% mehr Übertragungsraten bekommen im Vergleich zum OpenVPN… Sprich bei 12 Mbit/sek vorher (OpenVPN ohne Verschlüsselung) sind es bei mir auch nur um die 36 Mbit/sek mit L2TP(auch ohne Verschlüsselung) geworden.
ICETA 2024 Hier gibts noch Zahlen AES IPSec vs. AES OpenVPN: 99 Mbit/sek zu 142 Mbit/sek, also ist unter x86 scheinbar wirklich nur ~50% mehr rauszuholen. Da scheint dann die Verschlüsselung im Verhältniss doch mehr zu greifen als erwartet.