Posts by frank_m

    (Aber irgendwie hätte ich trotzdem erwartet, dass es die Engpässen in Richtung vom Sever mit der besser Anbindung zu dem mit der geringeren gibt und nicht umgekehrt)

    Ja, das sollte man erwarten. Der schnellere Server kann den langsameren ja fluten. Aber ich glaube, dass es nicht so ist, ist der beste Beweis, dass die TCP Algorithmen funktionieren.


    Ich hab spaßeshalber den Congestion Algorithmus mal von CUBIC auf BBR umgestellt. Ergebnis: Katastrophe. Die Retransmissions sind genau so hoch, aber die Bandbreite G8 -> G9 bricht auf 300 MBit/s zusammen. Das hatte ich anders erwartet.


    Aber: Die Algorithmen scheinen Einfluss zu haben. Vielleicht ein Ansatzpunkt für weitere Untersuchungen.

    HC -> RS G9 - Keine Retr.

    RS G9 -> HC - Viele Retr.

    Interessant. Ich hab von meinem G8 und G9 Server einen Test gegen den iperf3 Server von WilhelmTel gemacht. Der kann beide Server auslasten. Es gibt zwar ein paar Retransmissions, aber die sind locker um Faktor 20 kleiner, als in der direkten Verbindung der beiden RS.


    iperf versucht im TCP Modus natürlich, die Leitung möglichst auszureizen. Das heißt eben, die Leitung wird geflutet, bis es zu Paketverlusten kommt und die TCP Congestion Control Algorithmen zuschlagen. Von daher ist eine gewisse Anzahl Retransmissions normal. Man müsste das mal mit normalen wget Downloads gegentesten.

    Ich kann das Phänomen in gewissen Grenzen bestätigen.


    Ich hab einen RS 2000 G8 (1 GBit/s) und einen RS 2000 G9 (2.5 GBit/s). Sende ich vom G8 zum G9, gibt es diese Retransmissions. Sende ich vom G9 zum G8, gibt es sie nicht. Erster Verdacht: Es betrifft den Upload des G8 Servers, da der am Limit ist.

    Das sieht bei mir ähnlich aus, trotzdem komme ich auf die zu erwartenden Bandbreiten.



    Ich fürchte bei den Retransmissions suchen wir an der falschen Stelle. Bei den Tunnelversuchen weiter oben treten sie nicht in signifikanter Anzahl auf, und bei den direkten vServer Verbindnungen schränken sie die Bandbreite nicht dramatisch ein.

    Mit HE Tunneln hab ich eigentlich immer gute Erfahrungen gemacht. Da erreiche ich Bandbreiten bis an den Gigabit Bereich, auf jeden Fall hohe 3stellige Megabit Werte. Das sollte es also nicht sein.


    Es scheint ja eher auf Router Seite zu liegen, weniger auf RS Seite. Der Upload vom Router ist langsam, sobald Protokoll 41 in IPv4 Paketen verschickt wird (weil das macht HE ja auch so). Da würde ich als erstes suchen. Vielleicht sieht man was in einem tcpdump? Du hast auch nie mit tc herumgespielt oder mit DiffServ?

    Erhöhte Werte auf einzelnen mtr Hops sagen gar nichts aus. Das heißt lediglich, dass der Router ICMP Pakete mit geringer Priorität erzeugt. Er leitet sie aber mit hoher Priorität weiter, denn sonst wären alle Hops dahinter auch langsam. Sind sie aber nicht. Bei einem MTR ist meistens nur der letzte Hop interessant, das Ziel. Wenn die Werte dort in Ordnung sind, ist alles dazwischen irrelevant.


    Hast du mal die CPU Auslastung der beteiligten Geräte im Auge behalten? Hast du irgendwelche iptables oder traffic Shaper Regeln auf deinem Router aktiv? Es fällt ja auf, dass auch die HE Tunnel Ergebnisse mäßig sind.

    Welcher Router kommt denn zum Einsatz? Hast du testweise eine andere Gegenstelle für die Verbindung? Wie sieht die IPv6 Performance des RS 500 ins Internet aus?


    Welche Adressen nutzt du denn für IPv6? Aus dem /64 Netz des RS 500? Hat nur der Router eine IPv6 oder verteilst du lokal auch noch Adressen an die Clients des Routers?

    Aber es ergibt für mich einfach in der heutigen Zeit keinen Sinn, da doch alle Dateien vorhandne sind und die müssen lediglich in eine Datenbank eingefügt werden.

    Die Dateien müssen nicht in die Datenbank eingefügt werden. Die Datenbank hat mit diesen Dateien gar nichts zu tun, ihr Inhalt ist ein völlig anderer, der in keiner Datei gespeichert wurde. Wird es dir jetzt klar, warum diese Dateien dir überhaupt nicht weiterhelfen?


    Diese Dateien sind auf allen Wordpress Installationen gleich. Sie generieren die Webseite, indem sie die Inhalte aus der Datenbank auslesen und aufbereiten. Der Inhalt der Datenbank ist das entscheidende für die Webseite, nicht die Dateien.

    Dann sparst du dir faktisch schon den ganzen pain den du hier hast und als Kirsche auf der Sahne brauchst du nur ganze 6 Zeilen Konfiguration für deine Clients.

    Um das Routing muss er sich auch bei Wireguard schon noch selber kümmern. Dazu UDP only und die IP Konfiguration ... Ja, die Performance ist besser, wenn man mit den ganzen Einschränkungen leben kann.

    Mein Zweck dahinter ist, dass ich mich nicht mit blöden Routern rumschlagen muss die sich entscheiden ULA anders zu routen, schon die besten Stories erlebt.

    Bei ULA macht man natürlich NAT6, das kam in meinem letzten Post vielleicht missverständlich rüber.

    Da mir ein /64 Ipv6 netz zugeordnet ist, nutze ich einfach das Subnetz und trickse die Router aus und bisher hatte ich keinen Fall wo das nicht geklappt hat.

    Aber wenn du NAT6 mit diesen Adressen machst, dann sehen vorgeschaltete Router die gar nicht mehr.

    Es war nicht bei netcup, sondern bei einem anderen Webanbieter, aber da hatte ich auch mal so eine Warnung, und anschließend waren alle Daten weg. Ich hatte erfreulicherweise ein Backup, aber ärgerlich war es trotzdem.


    Das war dann der Moment, wo ich mir geschworen habe, nie mehr solche Webhosting Angebote zu nutzen, sondern nur noch RS/VPS Systeme. Da entscheide ich selber, wann was gelöscht wird.