Woher weiß mein Rechner mit welcher Geschwindigkeit er senden darf?

z.B. Slow Start


Macht Du die Leitung auch voll? Auf welcher Seite mißt Du?

lks

Hi Kismet,

das wird nicht dem Schicksal überlassen sondern permanent korrigiert.

Im Übertragungsprotokoll ist das verankert.
Es klappt ja auch mit DSL 0,75Mbit und 50Mbit/s.

Das dominierende Protokoll ist das TCP Protokoll und das wird mittels eines Dreiwegehandshakes betrieben. Es gibt für alles eine Bestätigung. Wenn also die Bestättigung innerhalb des Sendefensters (typisch ca 64KByte) ausbleibt, dann muss der schnelle Rechner eben warten, bis er weiter machen kann. Die Gegenstellen richten sich also auf die maximal erreichare Durchsatzgeschwindigkeit pro Richtung ein. Wenn schlechter wird, dann werden diese Fenster verkürzt und mehr Bestätigungen angefordert. Wenn die Verbindung besser wird, dann kann das Fenster auch ein Vielfaches der Ausgangsgröße erreichen. Dann wird die Verbindung schneller.

Das Verfahren wird zur Zeit auch bei Videostreaming eingesetzt und bei Web-TV und Webradio. Deshalb kann es sein, dass die Sendung trotz passender Bandbreite schon mal ein paar Minuten länger dauert. Ursprünglich sollte UDP dafür verwendet werden, tut aber kaum jemand. Ausnahme VoIP und interaktive Echtzeitanwendungen. Da riskiert man lieber eine Lücke als den unmenschlichen Zeitversatz.

Jetzt solltest du das auch im Wireshark finden.
Wie kannst du es schnell prüfen:
Lade eine große Datei von einem europäischen Server und von einem amerikanischen. Da das Handshake (Ping-Zeit) länger dauert, wird auch eine geringere Bandbreite genutzt.

Switches haben typischerweise am Wenigsten mit der Geschwindigkeit zu tun. Sie haben auch nur einen lokalen Fokus. Wenn das Paket weg ist, dann ist es weg. Kein weiteres interesse. Router schon eher ein, da die Router die Pakete umkodieren müssen.

Aber alles kein Layer2.

Gruß
Netman

Hallo Kismet,

wie sind die Switchports einstellt, Autonegoation oder feste Geschwindigkeit?

grüße vom it-frosch

-> http://de.wikipedia.org/wiki/Autonegotiation
Das regelt wie schnell deine Karte Senden und Empfangen kann. Du kannst das in den Einstellungen der Netzwerkkarte ueberschreiben.

Das Wireshark ueberhaupt problemlos laeuft ist manchmal bei den Bug und Pufferueberlaufen eher ein Wunder.

NetIO will maximalen Durchsatz und das ohne Rücksicht. Also UDP und maximal einstellen. Was verloren geht ist weg...
Wireshark ist ja auch nur ein Teil deines Systems und NetIO will genau messen, also volle Kanne, alle Resourcen, wenn nötig.

Gruß
Netman

Hallo kismet,

es gibt keine falschen oder dummen Fragen, denn niemand weiß alles.

Aber da Du dir die Frage selber eigentlich beantwortet hast, kommt es einem dann eben auch wieder ein klein wenig komisch vor.


Ist doch alles klar oder?
Tausch die Switche aus und gut ist es.

So nun zum messen, wenn Du die ganze Sache akkurat messen möchtest, kommt es natürlich auch auf das Equipment an was zum Einsatz kommt.

- Billiger Lanmeter (30 €)
- Fluke Lanmeter (Kauf Dir leiber ein Auto)
- Harware die mit Wireshark vertrieben wird (Kauf Dir lieber eine Wohnung)
- Extra Rechner wie zum Beispiel ein Linux Laptop
- Die Art, Beschaffenheit und die gebotenen Funktionen der eingesetzten Switche (Monitor oder Mirrored Port)
- Die Güte und Qualität der verbauten Netzwerkkarten und deren Treiber
- Das verwendete OS und vor allem anderen die darunter liegende Hardware
- Stehen Ethertabs zur Verfügung? und und und und......

Wenn Du uns schon schreibst:
Das ist doch wohl nicht die Schuld von Wireshark, sondern wohl eher der verwendeten Hardware geschuldet.

Einfach anklicken

Was für Filter hast Du denn in WireShark gesetzt?

Wenn alle Partner auf Autonegoation eingestellt sind, wie @it-frosch das nachgefragt hat, handeln diese
Netzwerkkarten und Switche das untereinander automatisch aus.

Ich denke eher das die beiden PC aufgrund der verbauten Netzwerkkarte dies unterstützen
und Du davon ausgehst das das dann auch so ist, allerdings begrenzen alleine die Switche das schon
von vorne herein. Denn wenn Dein PC eine 100 MBit/s Netzwerkkarte hat und an einen Switch angeschlossen
ist der nur 10 MBit/s kann, dann kann es ja nur einen 10 MBit/s Verbindung sein und nichts anderes!
Ob nun FullDublex oder HalfDublex spielt hier keine Rolle!

Mein Tipp an Dich:
Zwei 10/100/1000 MBit/s Netzwerkkarten kaufen
Billige gibt es für ca. ~6 € je Karte (Realtek basieren)
Etwas bessere gibt es für ~40 € (Intel basierend)
Zwei GB LAN fähige Switche organisieren
So wie das in Deiner Zeichnung aussieht ist das mit 40 € bis hin zu 120 € für zwei Switche erledigt.
Und das ganze Szenario kann dann auch schon einmal ganz anders ablaufen, denn wenn Du dann
einen freund oder Bekannten anrufst und die Messung noch einmal mit Wireshark veranstaltest
ist der Flaschenhals weg und mit einem Monitor Port am Switch und einen Linux Laptop kann man
zum einen mit Wireshark und zum Anderen mit iperf ganz schnell nachmessen was denn wann und wie
läuft.

Denn irgendwie, nimm es mir bitte nicht übel, habe ich das Gefühl das Du Dich da in was verbissen hast,
á la ich mach mich mal schlau und dann bekommen wir den Flaschenhals schon weg.
Falls das der Fall sein sollte ist das mit der neuen Hardware ein weitaus besserer Tipp bitte glaube mir.
Es ginge zur Not ja auch schon mit einem Switch, wenn man nur die Entfernung und den ganzen Rest kennen
würde!

Sollte das aber nur eine rein informative Frage sein, solltest Du vielleicht einen Laptop mit an den jeweiligen Switch hängen und noch einmal messen.

Gruß und viel Erfolg
Dobby

Hi Dobby,

Das hat hier absolut nichts mit einer spezifischen Hardware und mit Autonegationsproblemen zu tun.
Es geht um die Bits, die mal Ethernet über Kupfer Vollduplex, mal geshartes Medium wie WLAN oder Hub, mal WAN-Technologie (ATM, Ethernet, VPN, ISDN, PDH) sein können.

Der Vorgang ist immer der selbe und er funktioniert. Zum Glück für TCP.

Daraus ergibt sich auch, dass man Durchsatzmessungen nicht mit TCP machen kann, wenn es nur um die reale Bandbreite geht.
Die zweite Messmethode mit TCP von einem Server hat in jedem Falle auch die lokalen Leistungs- und Serverparameter mit drin. Wer will schon defekte Dateien benutzen. Bei TCP gibt es das nicht - dank der Ende zu Ende Verifikation der Pakete, die Zeit braucht.

Gruß
Netman

@kismet

Die Switche und niemand anderes, kein Protokoll und/oder sonst wer, nur die Switche.

Wenn die Switche 10/100 MBit/s können würden, wäre ja auch kein Flaschenhals mehr da, der ist
Hardware basieren oder besser Hardware existent und nicht Protokoll basierend!!!

Da kannst Du lesen bis Du den Doktorgrad erreichst, aber durch den Einsatz eines anderen Switches
ist das Problem, der Flaschenhals nicht mehr existent oder besser noch behoben.
Ist wie mit einem "platten" Reifen am Fahrrad, ist der erst einmal geflickt bzw. ausgetauscht, entweicht die Luft auch nicht mehr.

Wenn man nun einmal hergeht und sagt die Distanz zwischen den Switchen ist xyz Meter und man kauft einen 30 € Switch der 100 MBit/S kann ist der Flaschenhals weg, fertig.

Denn die Sendegeschwindigkeit der Netzwerkkarte mag ja 100 MBit/s haben, aber die des Switches eben nicht und daran ist der PC (die PCs) ja nun einmal angeschlossen!

Sei bitte nicht böse, aber es klingt mir so also ob:

Wenn Du einen Gartenschlauch hast und knickst den etwas, dann kommt eben auch kein Wasser oder nur noch ein bisschen Wasser mehr durch. Und Du möchtest Dich nun über die Wasserleitung und die beim Schlauch verwendeten Materialien schlau mach n(lesen) warum denn nur so wenig Wasser vorne aus dem Wasserschlauch kommt. Und ich versuche Dir eben nur zu erklären dass man nur den Schlauch nicht knicken
darf!

Viel Glück und Gruß
Dobby

Hallöle,

die Karte am PC ist Punkt eins der Verbindung und ist, obwohl sie 100 MBit/s können würde,
doch aber nur mit 10 MBit/s mit dem Punkt zwei, nämlich dem Switch verbunden, oder irre ich mich jetzt so
sehr. Zumindest wenn ich seine Zeichnung sehe, kann die Karte niemals auf 100 MBit/s eingestellt sein!
Somit sendet diese auch nicht mit 100 sondern eben nur mit 10 MBit/s.

Wenn es nicht so sein sollte, bitte ich jetzt einmal um Korrektur.

Gruß
Dobby

Hi dobby,

Da muß ich Dir widersprechen.

Wenn der PC an einem 100MBit-Switch vollduplex hängt, sendet der auch 100MBit vollduplex. Wenn es hinter dem switch nur mit 10 Mbit weitgergeht, schaltet er um auf store-andforward udn üuffert die Daten, bis sein Puffer überläuft. Ab da werden die Frames entsorgt.

D.h. der PC sendet ggf. weiter mit 100MBit, aber der switch leitet nicht alles weiter. Die höheren Protokollschichten müssen dann dafür sorgen, daß keine Datenverluste auftreten. Das kann TCP sein, oder aber auch andere Protokolle, die Fehlerkorrekturmechanismen implementiert haben.

TCP macht das mit u.a. "Flow-" und "Congestion Control".

lks

Ja ne schon klar


nun habe ich es auch gesehen!

ich bin die ganze zeit von pc 100mbit/s -------->10 MBit/s Switch---------10 MBit/s--------->.......

Wer lesen kann war klar im Vorteil.

Gruß und schönen Weltuntergang
Dobby

TCP verhindert nicht, daß Pakete verlorengehen. TCP sorgt nur dafür, daß Pakete nur so schnell gesendet werden, das möglichst wenig oder gar keine Pakete verlorengehen.

lks

Hi Kismet,

immer Syn Ack - das ist der Handshake.
Ohne ihn könnte man doch nicht erkennen, ob Pakete nicht ankommen oder ins Timeout laufen. Die Windowssize und das Vielfache davon, bestimmt nur die Datenmenge, die der Sender verschicken darf, ohne auf ein Ack zu warten. Damit hat man nicht nur die Bandbreite, sondern auch wackelige Verbindungen im Griff.
Eine Ausnahme gibt es im WLAN, das einen eigenen Layer2 Prozeß für verlorene Pakete hat. Der AP kontrolliert ja permanent die Verbindungen und bekommt es so mit. Deshalb der Prozeß des CSMA-CA mit der AP-Steuerung.

Während Wireshark beim Verbindungsaufbau gut zeigt, wie der Pozeß funktioniert muss man später sehr genau im Decode nachsehen für welche Paketnummer das ACK gesendet worden ist.

Gruß
Netman

https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Data_transfe ...

.@Lochkarte
Ein Switch "schaltet" niemals um auf Store and Forward, denn das kann er gar nicht, weil das in seinen Port ASICS fest vorgegeben, also in Silizium gegossen ist. Technisch kann ein Switch nur im cut through oder store and forward Mode arbeiten je nach Basis der verbauten Chips und Firmware.
Richtige Cut Through Switches sind extrem selten im Ethernet Bereich, da teuer was wieder die klassichen Kunden mit "HP Denke" nicht bezahlen wollen oder für unnötig halten. Das Gros aller Ethernet Switches, außer speziellen Rechenzentrums Fabric Switches, arbeitet immer mit Store and Forward. "Umschalten" ist also technischer Unsinn.

Ansonsten ist zu dem Thema ja bereits alles gesagt und die Testergebnisse von kismet bestätigen ja auch genau die Theorie in der Praxis.
Was maximal gesendet werden kann bestimmt einzig der Sliding Window Mechanismus unter TCP:
http://de.wikipedia.org/wiki/Sliding_Window
Nur damit ist eine Flusskontrolle überhaupt möglich in dem obigen Szenario, denn die 100 Mbit attachten Endgeräte wissen ja nichts vom 10 Mbit Engpass dazwischen. In der Beziehung ist der Einwand mit der Autonegotiation natürlich auch Unsinn !
So oder so ein klassisches Szenario bezogen aufs gesamte Internet. Die Exchange Points haben alle 100 Gigabit Ethernet Glasfaser oder sogar mehrere davon in einer Link Aggregation. Ein Enduser aber nur 3 Mbit DSL...gleiches Spielchen nur andersrum was aber der Theorie keinen Abbruch tut.
Bei anderen Protokollen die keinen Sliding Windows Mechanismus haben pumpt der Switch eben alles raus was er kann und seine HW hergibt, bzw. was seine DRAM Port Puffer aufnehmen können auf dem 10 Mbit Port. Port Buffer sind je nach Switchqualität und QoS Fähigkeit (mehrere Port Buffer Queues für Priorisierung) sehr unterschiedlich.
Wenn diese Port Buffer voll sind schmeisst er gnadenlos weg, was aber das angeschlossene 100 Mbit Endgerät nicht merkt ohne Sliding Windows.
802.3x Ethernet Flow Control wäre ein Mechanismus das Geräte basierend zu lösen:
https://www.juniper.net/techpubs/en_US/junos/topics/concept/cos-qfx-seri ...
Dann hätte man dies Flusskontrolle auf Basis der verwendten Infrastruktur. Wäre ideal, aber leider ist das beim Gros der Switches und auch der NICs nicht implementiert oder gar nicht aktiviert.
Inkonsistente Konfigurationen mit und ohne 802.3x Funktion auf Switches können somit zu erheblichen Problemen in Ethernet Netzwerken führen wo sowas kritiklos gemischt wird. Ein tägliches Problem hier bei Administrator.de da kein Hobby Netzwerk Admin auf sowas achtet geschweige denn Kenntniss davon hat. Die vielen Threads hier zeugen davon...
Genau das ist auch der Grund warum es auf dem Gros der ungemanagten Billigswitches gar nicht implementiert oder bei billigen Midrange Switches (und Highend im Default) nie aktiviert ist. Die meisten NIC Treiber haben es in den Settings ebenfalls deaktiviert. 802.3x ist sinnvoll angedacht aber in den meisten Ethernet Netzen kein Themaaus den genannten Problematiken.
Fazit ist, das damit mehr oder weniger alles von höheren Protokollschichten abhängt. Im reinen Layer 2 wird nur weggeschmissen bzw. gedropt, so einfach ist das.
Letztlich auch genau das, was die o.a. Testergebnisse ja bestätigen !

...ist ja Weihnachtszeit