|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
Obs fuer den Otto-Normal Enduser, der nicht ueber einen x Mbit/s Link etwas bringt, ist doch fraglich...
Schliesslich stellt ja die maximale Uebertragungsrate der Leitung eine obere Schranke dar...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 05. July, 18:33 MES (#2)
|
|
|
|
|
TCP hat Probleme mit schnellen Leitungen oder mit Verbindungen, die eine hohe Latenz (Distanz!) haben. Dies wird durch das ACK-Handling der Packete verursacht.
Es ist wohl eher so, dass der Link in diesem Beispiel "nur" 1Gbit/s hatte, FastTCP (ack von mehreren Packeten, so weit ich weiss) auf 920Mbit/s kommt, TCP nur auf 266.
Es gibt ja noch ATM, SDH etc..
|
|
|
|
|
|
|
|
|
|
|
|
|
Mal ne Frage: wie kann TCP schneller als IP drunter sein?? Selbst wenn man das ACK-Handling und 3-Way-Handshaking verbessert, mehr als IP-Pakete sind das auch nicht...
--
$ cd /dos/c/MICROSO~1
$ rm -rf *
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Der "Flow Control" ist auf dem TCP-Layer implementiert. IP wird nicht schneller, das Netz wird IMHO einfach "optimistischer" beurteilt.
|
|
|
|
|
|
|
|
|
|
|
|
|
Sollte nicht genau das durch TCP vermieden werden? Wenn ein System überlastet ist, soll TCP die Leitung drosseln und langsam wieder hochfahren, damit das System nicht gleich wieder einbricht.
Wird das nun optimistischer beurteilt, würde sowas also anders laufen und somit schwache Server öfter zusammenbrechen - dann für alle statt wie bisher nur für einzelne und der Rest bekommt langsam noch was.
--
$ cd /dos/c/MICROSO~1
$ rm -rf *
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ich wuerde in einer Mailingliste auf eine URL hingewiesen:
http://www.heise.de/newsticker/data/je-28.03.03-000/
mch
|
|
|
|
|
