TCP Tuning

[Kr0e]

Hi,

habe in paar Geschwindigkeits- und CPU-Lastprobleme mit der Übertragung von Daten übers Netzwerk. Ich denke es liegt an den Socket Sende/Empfangspuffergrößen. Hab ne ganze Menge gelesen und bin zum Schluss gekommen, dass das eigentlich
die einzigen Faktoren sind, um die ich mir noch keine gedanken gemacht hab. Der Ablauf des Programms ist ansich soweit ausgereift und ich finde auch keine Stellen mehr, wo man evt. optimieren könnte... Ich benutze zur Zeit standard Puffergrößen von jeweiles 8192 byte. Der folgende Artikel erklärt die Gefahr bei falsch gewählten Puffergrößen recht gut.

http://publib.boulder.ibm.com/infoc...e.express.doc/info/exp/ae/tprf_tunetcpip.html

Besonders interessant fand ich folgenden Satz:

"Die Flusssteuerung kann eine beträchtliche Menge an CPU-Zeit beanspruchen und aufgrund der Unterbrechungen der Datenübertragung zu einer höheren Latenzzeit im Netz führen."

Ich glaube, dass bei mir genau dieses Problem auftritt. Ich benutze Apache Mina, wodurch eine solide und flotte Basis gegeben ist.

Jetzt meine Frage: Kennt ihr das Problem ? Hohe CPU Last beim simplen übertragen von Dateien ? Oder generell zu langsame Übertragungen ?

Außerdem ist mri aufgefallen, dass das Problem mit der hohen CPU Last auf jeden Fall Software bedingt ist. (Nein, ich habe keine REALTEK Netzwerkkarte Sondern eine gute Intel... Daran liegts nicht) Vorallem, weil der Explorer bei Übertragungen nicht mehr als 4 % benutzt, und mein Java Progamm 60 % auf allen 4 Kernen... Und das bei einem QuadCore ?! Naja, ich weiß nicht...

Dachte erst an einem Programmierfehler, ist aber unwahrscheinlich. Hab den Test mal mit dem Apache Mina FTP Server wiederholt. Selbes Resultat! Entweder ist das ne Schwachstelle in Java (Stichwort MultiCore.. Ich habe ehrlich gesagt keine Ahnung inwiefern Java das kann oder auch nicht...), oder der FTP Server von Apache hat auch Standardpuffergrößen... Sofern das wirklich das Problem ist! Das Problem ist bei mir damals schonmal aufgetreten. Da hatte ich aber noch nen alten PC und dachte es läge iwie daran... War wohl ein Fehler...

Wie wählt ihr Puffergrößen ? Oder kennt ihr diese Probleme garnicht ? Woran könnte es liegen, wenn ihrs nicht kennt ?

Danke schonmal

Gruß,
Chris

 

[Gast2]

etwas Quellcode wäre hilfreich ... ansonsten würde ich daruf tippen das Du jedes Byte einzeln schickst

 

[HoaX]

Was mich stutzig macht sind die 60% auf allen 4 Kernen. a) wieso alle 4 und nicht nur einer, da nur ein Thread und b) warum 60%? Gibt es so lahme Quadcores oder was wird da soviel gerechnet?

 

[Kr0e]

Genau das wundert mich ja auch ! Die 60 % sind auch beim FTP Server von APache Mina, ... Spiele wie Far CRy 2 brauchen vlt 40 - 50 % aber 60 auf allen 4 ? Hört sich bald so an, dass alle 4 das Selbe machen, Ich versteh das nicht Aber auf jedem Rechner auf dem ichs getestet hab ... Überseh ich irgendwas ganz bestimmtes ?!

 

[Gast2]

Du machst was ganz komisches ... im Normalfall schaufelt die CPU die Bytes nur zur Netzwerkkarte - die schickt das dann weiter ... das geht sogar so weit das Du mehrere MB in eine ISDN Leitung pumpen kannst - in ein paar Sekunden ... dann wirds erst übertragen - langsam

 

[Kr0e]

Also soll ich auf einen Socket z.B. nicht in 8192 byte Blöcken senden, sondern in 4MB oder so ?!?!

 

[Kr0e]

Habe es jetzt tatsächlich geschafft! Das ändern der Puffergrößen war die Lösung... vlt. auch wichtig für Leute mit dem selben Problem. Habe jetzt einen Sende und Empfangspuffer von 4 MB außerdem habe ich den Nagle-Algorithmus aktiviert, was für große Dateien sinnvoll ist. Übertrage Daten nun mit 97% Netzwerk und 2 % CPU. Unglaublich was falsch eingestellte Puffergrößen verursachen können.

 

[Gast2]

sollte das wirklich an den Puffer gelegen haben, dann ist da was in Mina kaputt ... ich habe das noch nie erlebt ... 8kByte haben immer gereicht - egal wie groß die Datei war

 

[Kr0e]

Ist für mich schwer zu glauben.... Habe auch schon sämtliche "simple" Java Socket Lösungen probiert. An Mina kanns nicht liegen. Der FEhler liegt eine Ebene "tiefer" als Mina überhaupt agiert. Auch mit normalen Sockets wird der Fehler durch Angleichen der Puffergrößen eliminiert. Und wie der Link von mir weiter oben zeigt, ist dies offenbar keine Seltenheit. Wenn IBM genau zu diesem Thema einen Artikel veröffentlich, so muss da schon eine gewisse Notwendigkeit vorhanden sein! Stichwort: Flow control

Wie dem auch sei... Mein PRoblem ist gelöst, wenns bei dir so klappt, Glückwunsch^^ Aber für Andere mit dem selben PRoblem ist das dann vlt. eine ganz hilfreiche Sache...

Gruß,

Chris

 

[tuxedo]

Ich glaube wir hatten das Thema schonmal....

Von welchen Puffergrößen sprichst du? Wirklich der Netzwerkpuffer den man auf Sockets einstelen kann? Oder die Fragementierung mit der du Dateien in den Netzwerkpuffer schiebst?

Den Puffer auf Socket-Ebene hab ich nach wie vor bei 8kbyte (Standard). Wenn ich kleine Files lese und verschicken will, hab ich ne recht kleine fragmentierung. Meist irgendwas <500kybte.

Wenns große Files sind, sagen wir mal >100MB, dann lese und schreibe ich in größeren Blöcken. Da sinds dann auch mal >1MB.

- Alex