Netzwerkprogrammierung - Paketgröße
-
beim Übertragen großer Datenmengen fällt das natürlich ins Gewicht.
Du kaufst dir ja auch nicht ein Auto, dass mal eben so 10% des Treibstoffes einfach ohne nutzen wegbrennt.
-
akoww schrieb:
Du kaufst dir ja auch nicht ein Auto, dass mal eben so 10% des Treibstoffes einfach ohne nutzen wegbrennt.
natürlich hast du durch die Header nen Nutzen. Sinnlos werden die Bytes nicht verschwendet
Und welchen Buffer meinst du?
-
Ne aber du kaufst dir ein Auto mit Lichtmaschine.
-
akoww schrieb:
Nun meine Frage: Wieso setzt man setzt man meistens so einen kleinen Buffer von <2048Bit ein? Das rechnet sich doch gar nicht, weil schon ein teil für den Header verwendet wird den man selbst benutzt.
Du wirst einen Schock bekommen, wenn du erfährst wie groß ein Sektor auf allen Festplatten bis vor 1-2 Jahren war: 512 Bytes.
Erst vor kurzem wurde bei großen Platten die Sektorgröße auf 4096 Bytes angehoben. Es gibt aber auch noch 2TB-Festplatten mit 512-Byte-Sektoren. Die haben also 2 Billionen Bytes unterteilt in lachhaft kleine Blöcke zu je 512 Bytes, und jeder 512-Byte-Block enthält natürlich einige Bytes zusätzlich für Fehlerkorrektur, bestimmt auch um die 10%.
Kleine Blöcke haben aber natürlich auch Vorteile: Wenn du eine Datei anlegst, die nur ein paar Bytes groß ist, muss die Platte im Idealfall nur 512 Bytes schreiben statt 4096 Bytes wie aktuelle Platten. Andererseits ist die Zeit, die die Platte braucht um einen bestimmten Sektor zu finden, sowieso um Größenordnungen höher als der Unterschied zwischen "512 Bytes schreiben" und "4096 Bytes schreiben". Kostspielig wird es nur, wenn die Software nur einen halben Sektor ändern möchte und dafür den Sektor erstmal einlesen muss bevor er geschrieben werden kann. Da sind kleine Sektoren wieder von Vorteil.
Das wirkt sich bei RAIDs aber viel deutlicher aus. Wenn du zum Beispiel ein RAID6 unter Linux hast, dann hat das standardmäßig eine chunk size (d.h. Blockgröße) von 512kB. Wenn du 10 Platten in dem RAID hast, sind das 8 Datenplatten, also ist ein stripe 512*8 = 4MB groß. Wenn das Dateisystem oder eine Software jetzt weniger als 4MB auf einmal schreiben möchte, dann muss der RAID-Treiber erstmal 4MB lesen, um dann die 4MB mit neuer Parität neu schreiben zu können. Das ist einer der Gründe, warum RAID6 vergleichsweise langsam ist bei kleinen Schreibzugriffen.
Eine Blockgröße von 512kB ist meistens vernünftig, denn der Overhead ist dadurch insgesamt geringer. Aber bei RAID sieht man eben auch, dass eine größere Blockgröße nicht nur Vorteile bringt: Wenn man häufig viele kleine Dateien schreiben möchte, ist 512kB vermutlich nicht die optimale Blockgröße, und man sollte eine kleinere wählen. Schreibt man ausschließlich sehr große Dateien, dann könnte eine Blockgröße von 1MB sogar besser sein.
Blockgrößen sind immer ein trade-off. Eine Faustregel ist, dass größere Blockgrößen hohen Durchsatz ermöglichen, weil der Overhead insgesamt geringer ist. Kleinere Blockgrößen ermöglichen dafür eine geringere Latenz, weil kleinere Blöcke schneller verarbeitet werden können als große. Das trifft auf meine Beispiele oben zu.
-
@akoww:
Also du hast hier hübsch Bits und Bytes vermischt.
Es sind 1500 Bytes, und das ist deutlich viel mehr als 2048 Bits.akoww schrieb:
beim Übertragen großer Datenmengen fällt das natürlich ins Gewicht.
Ui, ich verschwende 3,2% der Bandbreite, uiii.
Ganz ehrlich: wen interessiert das? Mich nicht.Und wenn du nach dem warum fragst: guck mal wie lange es Ethernet schon gibt. 1500 Byte schneller Speicher waren damals kein Schmutz. Vor allem wenn man ihn zigfach braucht, für Router/Switches etc. Bzw. für Kleinstgeräte die auch gerne Daten über
TCP/IPEthernet übertragen möchten.
-
hustbaer schrieb:
@akoww:
Also du hast hier hübsch Bits und Bytes vermischt.
Es sind 1500 Bytes, und das ist deutlich viel mehr als 2048 Bits.Ich glaube er hat sich nur verschrieben
-
Steh ich auf dem Schlauch? TCP kennt doch gar keine Pakete und wie die unteren Schichten die Daten zusammenpacken sollte uns doch egal sein? Ist nicht sowieso Nagle's auch per default aktiviert?
-
Schlaucher schrieb:
TCP kennt doch gar keine Pakete
Hä?
-
Er meint, daß TCP stream orientiert ist im Gensatz zu Datgramm orientiert.
-
Für den Benutzer gibts keine Pakete in TCP. Aber die (nicht ganz triviale) Implementierung von TCP auf IP verwendet natürlich Pakete...
