Datenmengendifferenz bei unterschiedlichen Bandbreiten

[TheVision]

Hallo Zusammen,

folgendes ist mein Problem:

Ich habe eine größere SQL Abfrage. Nun habe ich festgestellt, dass wenn ich meine Netzwerkkarte auf automatischer Ermittlung von Geschwindigkeit und Duplex (ist eine 100Mbit Karte) stehen habe diese Abfrage vom MS-SQL Server zum Client ca. 27000-33000 Pakete und ca. 29-33 Mbyte an an Datentransfer erzeugt.

Stelle ich nun meinen Netzwerkkarte von auf 10 MB Half Duplex um (Full Duplex funktioniert nicht, daher hier außen vor) und führe die exakt selbe SQL-Abfrage aus (an der Datenquelle hat sich während der Umstellung nichts geändert), wächst der Datentransfer vom Server zum Client auf einmal auf fast immer exakt 53900 Pakete und 48.9 MByte Daten an.

Auf diesen Versuch bin ich gekommen, weil mir aufgefallen ist das beim Kunden immer wesentlich mehr Datenmengen übertragen werden als mit der selben Datenbank bei uns im Firmennetwerk.

Durch diesen Versuch stellen sich natürlich jetzt die dringende Frage, die ich mir und leider auch niemand bei uns in der Firma beantworten kann: Was soll das ?? :confused::confused::confused:

Wie können die immer exakt gleich angeforderten Daten bei verschiedenen Bandbreiten (simuliert durch das manuelle Umstellen der Netzwerkkarte) solche durchaus dramatischen Änderungen an der übertragenen Datenmenge verursachen, obwohl ja die angeforderten Daten exakt die selben sind....

Kennt jemand von euch dieses Problem, weiß woran es liegt, was man dagegen tuen kann und so weiter und sofort.

Über Hilfe wäre ich extrem Dankbar.

Viele Grüße

Michael

[Crash2001]

Von 100MBit/s Full Duplex auf 10Mbit/s half duplex, oder von 100MBit/s halfduplex nach 10MBit/s halfduplex? :confused:

Wenn von fullduplex auf halfduplex umgestellt wird, dann kann das durchaus an den Kollisionen liegen. Wenn eine Kollision auftritt, muss das oder die entsprechenden Datenpakete noch einmal übertragen werden. Bei full duplex können keine Kollsionen auftreten, weshalb die übertragende Datenmenge insgesamt dann geringer ist.

Wenn von 100half auf 10half umgestellt wurde, kommt das hingegen nicht als Grund in Frage. Da könnte dann höchstens sein, dass, da es ja ca. 10 mal so lange dauert bei der Übertragung, in der Zeit auch mehr Kollisionen auftreten können.

[ardcore]

Wenn von fullduplex auf halfduplex umgestellt wird, dann kann das durchaus an den Kollisionen liegen. Wenn eine Kollision auftritt, muss das oder die entsprechenden Datenpakete noch einmal übertragen werden. Bei full duplex können keine Kollsionen auftreten, weshalb die übertragende Datenmenge insgesamt dann geringer ist.

Crash2001 hat recht, es liegt an den Kollisionen.

Weise den Kunden daraufhin das er seine Server/Switch-Verbindung auf

einen Duplex-Mismatch hin untersuchen soll.

Grundsätzlich gilt beide Seiten auf AutoNeg laufen lassen oder beide Seiten fest einstellen. Jedoch nie eine Seite fest und die andere auf Auto.

Gruss,

ardcore.

[TheVision]

Okay, das werde ich mal checken.

Aber erklärt das auch, warum (abgesehen von dem oben beschriebenen Duplex Mismatch bei Server/Switch) auch ein deutlicher Unterschied der Datenmengen zwischen 100MB Half Duplex und 10MB Half Duplex besteht? Denn damit kann ich auch eine Differenz feststellen. Denn so wie ich es gerade verstanden habe, ist der Duplex Mode und nicht die Geschwindigkeit für das Wachsen der Datenmengen verantwortlich. Wie ließe sich das dann noch erklären?

Viele Grüße

Michael

Bearbeitet 2. April 2009 von TheVision

[ardcore]

Okay, das werde ich mal checken.

Aber erklärt das auch, warum (abgesehen von dem oben beschriebenen Duplex Mismatch bei Server/Switch) auch ein deutlicher Unterschied der Datenmengen zwischen 100MB Half Duplex und 10MB Half Duplex besteht? Denn damit kann ich auch eine Differenz feststellen. Denn so wie ich es gerade verstanden habe, ist der Duplex Mode und nicht die Geschwindigkeit für das Wachsen der Datenmengen verantwortlich. Wie ließe sich das dann noch erklären?

Viele Grüße

Michael

Auch hierfür gibt es einen Grund. Wenn du scharf nachdenkst kommst du von selber darauf und weisst dann wie das Problem zu lösen ist.

Was ich schade finde ist das es keiner in deiner Firma weiss.

Wenn ich fragen darf:

Bist du noch in der Ausbildung? Was sagt dein Ausbilder zu diesem Problem?

PS: Als kleiner Tipp - es hat was mit dem verwendeten Protokoll zu tun.

Gruss,

ardcore.

[TheVision]

Nein, bin nicht mehr in der Ausbildung. Hatte aber auch Fachrichtung Anwendungsentwicklung und nicht Systemintegration, daher hab ich nicht wirklich Ahnung von TCP/IP außer den Grundlagen wie 3way Handshake und den Krams.

Und mit diesen Grundlagen kann ich mir das leider nicht erklären. Pakete werden nur neu gesendet, wenn sie verloren gehen. Ob die Netzwerkkarte nun 1Gb, 100MB oder 10MB entgegennehmen kann sollte doch hierbei keine Rolle spielen, die Daten dürfen deswegen ja nicht verloren gehen nur weil sie länger brauchen eh sie durch die Leitung können?! Oder spielen hier Timeouts der einzelnen Pakete ne Rolle?

Viele Grüße

Michael

[ardcore]

Nein, bin nicht mehr in der Ausbildung. Hatte aber auch Fachrichtung Anwendungsentwicklung und nicht Systemintegration, daher hab ich nicht wirklich Ahnung von TCP/IP außer den Grundlagen wie 3way Handshake und den Krams.

Und mit diesen Grundlagen kann ich mir das leider nicht erklären. Pakete werden nur neu gesendet, wenn sie verloren gehen. Ob die Netzwerkkarte nun 1Gb, 100MB oder 10MB entgegennehmen kann sollte doch hierbei keine Rolle spielen, die Daten dürfen deswegen ja nicht verloren gehen nur weil sie länger brauchen eh sie durch die Leitung können?! Oder spielen hier Timeouts der einzelnen Pakete ne Rolle?

Viele Grüße

Michael

War nicht böse gemeint die Frage, sollte auch kein Vorwurf sein das du das nicht weisst.

Nein, die Timeouts der Pakete an sich sind hier irrelevant. Paket-Timeouts sind meistens Probleme auf der Applicationebene (OSI-Layer 5+) und damit müssen sich Netzwerker zum Glück seltenst befassen

Was hier die grösseren Datenmengen verursacht ist die Flow-Control von TCP die dauerhaft versucht eine grössere Window-Size auszuhandeln. Da aber beide Interfaces verschiedene Bandbreiten fahren gehen viele Acknowledgements und Retransmits auf Grund der unterschiedlichen Interfacekapazität über die Leitung.

Mit einer entsprechenden Erhöhung der Interfacebuffer kann man dem entgegenwirken. Am Besten ist aber auch hier eine Gleichstellung der Interfacegeschwindigkeiten. Oder aber die Verwendung von einem verbindungslosen Transportprotokoll wovon ich aber bei Datenbanktransaktionen nur abraten kann.

Gruss,

ardcore.

[TheVision]

Danke! Das sind doch mal etliche Ursachen, die wir jetzt mal Versuchen zu verifizieren bzw. zu beheben. Da das ganze beim Kunden aber ein nicht gerade kleines Netzwerk mit u.a. einer 10Mbit WAN Strecke ist, freu ich mich da schon riesig drauf ... *

Wenn ichs recht verstanden habe kann also auch neben der Duplex Mismatch Problematik die unterschiedliche Interfacegeschwindigkeit von Server <> Switch/Router <> Client eine wachsende Datenmenge hervorrufen? Sprich der Server hat ne Gbit Netzwerkkarte drin, der Router und die Clients haben aber nur 100MBit Karten. Das würde schon den permanenten Versuch der Aushandlung einer Window Size hervorrufen?

Viele Grüße

Michael

Bearbeitet 2. April 2009 von TheVision

[Crash2001]

Wenn der Sender einen höheren Durchsatz als der Empfänger hat (z.B. auf einem Switch von 1GBit/s auf 100MBit/s, dann kann es passieren, dass der Puffer des langsameren Interfaces einfach voll läuft und dann alle Pakete die danach kommen und nicht mehr in den Puffer passen, einfach gedroppt werden.

Retransmits gibt es übrigens nicht nur für die Pakete die gedroppt wurden, sondern auch, wenn Bestätigungen über empfangene Pakete nicht innerhalb eines bestimmten Zeitraums an den Absender zurückgelangen, oder die Checksum nicht mehr übereinstimmt (zumindest bei verbindungsorientierten Protokollen wie TCP - verbindungslose erwarten ja keine Bestätigung/Rückmeldung vom Empfänger).

Du solltest zwei Interface die miteinander reden IMMER auf der gleichen Geschwindigkeit und gleichem Duplex-Modus laufen lassen. Egal ob das nun fest eingestellt wird, oder dynamisch ausgehandelt wird zwischen den Interfaces. Alles andere führt zu Problemen.

Werden x Pakete ohne Probleme übertragen, so kann die Windowsize automatisch erhöht werden.

Bearbeitet 2. April 2009 von Crash2001

[hades]

Die TCP Window Size spielt bei Windows Systemen auch noch eine andere Rolle.

Es gibt bis einschliesslich Windows XP/2003 kein aktiviertes TCP Window Scaling (RFC1323) und der default Wert fuer die TCP Window Size (je nach Windows OS/SP liegt der im Bereich 17 bis 38 KByte) ist sehr oft zu klein gewaehlt.

Das ist fuer Gigabit-Leitungen im LAN eine nicht zu unterschaetzende Bremse und kann bei im Internet veroeffentlichten Windows Systemen je nach Anbindung und Dienst/Zielgruppe auch bremsend wirken.

D.h. hier sollte man ueberlegen ob man per Registryeintrag a) das TCP Window Scaling aktiviert und die maximal moegliche TCP Windows Size auf die Gegebenheiten anpasst.

Eine andere Bremse kann die bei Windows Fileservern nicht optimal eingestellte Groesse des SMB Buffers sein.

[TheVision]

Vielen Dank für alle die Tipps, werden uns das alles mal anschauen und hoffentlich einiges an Performance aus (in) der die Leitung reinprügeln

Viele Grüße

MIchael