47
Was bringen die TCP Offload Features der Hardware, wenn die TCP Offload Engine in Windows seit etwa 3 Jahren deaktiviert ist?
Moin Zusammen,
ich wurde gestern bei Spiceworks von einem anderen Forenuser auf das Folgende hingewiesen.
Ich habe dazu gestern etwas rumgeforscht und tatsächlich ist die TCP Offload Engine mit Windows 1709 und dem Server 2016 aus dem Betriebssystem geflogen.
Siehe auch.
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ ...
https://docs.microsoft.com/en-us/windows-server/networking/technologies/ ...
Für mein Verständnis, sind damit sämtliche Hardwareseitigen TCP Offload Features der Netzwerkkarten damit für die Katz, da diese betriebssystemseitig (TCP Stack) nicht mehr unterstützt/angesprochen werden.
Darunter fallen meiner Meinung nach, die folgenden Kandidaten.
Was ist Eure Meinung dazu?
Siehe auch Swesterbeitrag bei Spiceworks (englisch)
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
Grüsse aus BaWü
Alex
ich wurde gestern bei Spiceworks von einem anderen Forenuser auf das Folgende hingewiesen.
Ich habe dazu gestern etwas rumgeforscht und tatsächlich ist die TCP Offload Engine mit Windows 1709 und dem Server 2016 aus dem Betriebssystem geflogen.
Siehe auch.
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ ...
https://docs.microsoft.com/en-us/windows-server/networking/technologies/ ...
Für mein Verständnis, sind damit sämtliche Hardwareseitigen TCP Offload Features der Netzwerkkarten damit für die Katz, da diese betriebssystemseitig (TCP Stack) nicht mehr unterstützt/angesprochen werden.
Darunter fallen meiner Meinung nach, die folgenden Kandidaten.
Was ist Eure Meinung dazu?
Siehe auch Swesterbeitrag bei Spiceworks (englisch)
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
Grüsse aus BaWü
Alex
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 592409
Url: https://administrator.de/contentid/592409
Ausgedruckt am: 28.11.2024 um 21:11 Uhr
47 Kommentare
Neuester Kommentar
NICs/CNAs können hardwareseitig diverse Offloader.
Wenn es für das OS wichtig ist, dann ist der Treiber vordergründig dafür verantwortlich.
Wichtig ist ja, dass die CPU entlastet ist, weil das SOC des NICs/CNAs die "Arbeit" hat.
Halbwegs moderne Hardware hat jedoch keine "Arbeit" mehr für die CPU, weil die NICs/CNAs hardwareseitig beschleunigt sind und die Treiber noch dafür benötigt werden um im grafischen vielleicht Einstellungen einsehen oder ändern zu können.
Wenn es für das OS wichtig ist, dann ist der Treiber vordergründig dafür verantwortlich.
Wichtig ist ja, dass die CPU entlastet ist, weil das SOC des NICs/CNAs die "Arbeit" hat.
Halbwegs moderne Hardware hat jedoch keine "Arbeit" mehr für die CPU, weil die NICs/CNAs hardwareseitig beschleunigt sind und die Treiber noch dafür benötigt werden um im grafischen vielleicht Einstellungen einsehen oder ändern zu können.
Das eine ist das OS, das andere sind die Treiber, meist die vom Hersteller und damit sprechen diese explizit die NIC HW an, die Zeiten, in denen die NIC von der CPU gesteuert (=OS) und berechnet wurden sind Gottseidank seit ein paar Jahren durch...
Naja, depricated heißt ja erstmal das feature als "alt" markiert ist - aber nicht sofort deaktiviert wird.
d.h. das funktioniert schon noch wenn der Treiber das unterstützt, aber man sollte sich als Entwickler darauf einstellen das das Feature nicht weiterentwickelt werden sollte. (Vermutlich ist es so dann wenn ich den NIC Treiber durch den IDE/Compiler für Win10 jage, dann meckert er eben das jegliche functionscalls zum Thema TCPOffload depricated sind und ich mich gefälligs drum kümmern soll - als verantwortungsvoller Entwickler stellt man dann den Compiler so ein das er die Warnungen unterdrückt und ändert nichts am code :D )
Da das Thema sowieso wohl umstritten war (man gibt den ggf. sensiblen Netzwerktraffic der "Blackbox Firmware" der NIC) - ist es vielleicht gut das es wegkommt.
Das ist ja eine Entwicklung die immer wieder kommt, es wird immer wieder Zeug ausgelagert (z.B. kennst du noch die MPEG-2 Beschleunigerkarten?) um es zurück zur CPU zu holen.
d.h. das funktioniert schon noch wenn der Treiber das unterstützt, aber man sollte sich als Entwickler darauf einstellen das das Feature nicht weiterentwickelt werden sollte. (Vermutlich ist es so dann wenn ich den NIC Treiber durch den IDE/Compiler für Win10 jage, dann meckert er eben das jegliche functionscalls zum Thema TCPOffload depricated sind und ich mich gefälligs drum kümmern soll - als verantwortungsvoller Entwickler stellt man dann den Compiler so ein das er die Warnungen unterdrückt und ändert nichts am code :D )
Da das Thema sowieso wohl umstritten war (man gibt den ggf. sensiblen Netzwerktraffic der "Blackbox Firmware" der NIC) - ist es vielleicht gut das es wegkommt.
Das ist ja eine Entwicklung die immer wieder kommt, es wird immer wieder Zeug ausgelagert (z.B. kennst du noch die MPEG-2 Beschleunigerkarten?) um es zurück zur CPU zu holen.
Moin NetzwerkDude,
Es wurde schon beim 2012R2 Microsoft seitig deaktiviert und ist mit dem Server 2016 / Windows 10 1709 komplett herausgeflogen.
Grüsse aus BaWü
Alex
Naja, depricated heißt ja erstmal das feature als "alt" markiert ist - aber nicht sofort deaktiviert wird.
d.h. das funktioniert schon noch wenn der Treiber das unterstützt, aber man sollte sich als Entwickler darauf einstellen das das Feature nicht weiterentwickelt werden sollte.
d.h. das funktioniert schon noch wenn der Treiber das unterstützt, aber man sollte sich als Entwickler darauf einstellen das das Feature nicht weiterentwickelt werden sollte.
Es wurde schon beim 2012R2 Microsoft seitig deaktiviert und ist mit dem Server 2016 / Windows 10 1709 komplett herausgeflogen.
Grüsse aus BaWü
Alex
Also die von dir geposteten Links sagen eigentlich was anderes:
also das ist auch ein Thema... gab mal vor ein paar Jahren Streß mit dem RSS, weil Windows 2012 R2 das pauschal bei Erkenung einer 10 GBit Karte aktiviert hat... auch wenn die physische Karte das garnicht konnte. Unter ESX 6.0 und VMXNET aus den VMwaretools 10.0.5 und niedriger war damit die empfangende Richtung so gut wie tot.
Und wir hatten vor nicht mal einem Jahr das Problem, daß das TCP Chimney Offloading aktiv geschaltet war, weil die linke Hand des IT-Dienstleisters nicht wußte was die Rechte tut und beide der Meinung waren, daß sie keine Fehler gemacht hatten. Und es gab noch 6 weitere Hände wie bei Kaili, der indischen Göttin mit 8 Armen... wir doktorn da im 1st und 2nd Level Support mehr als ein Jahr daran herum und konnten das zumindestens mal reproduzieren wenn 20 User auf einem Citrix-Host aktiv waren.
Effektiv gab es einen daramatischen Zuwachs an Citrix Latenzen bis zu 1000 ms. Nachdem der Dienstleister einen Krisenmaanger bestellt hat und der dann mit ca. 20 Leute in einen Meetingraum gesperrt wurde hatten sie das Problem innerhalb von 2 Tagen gelöst und es war genau diese eine Einstellung... es kommt immer mal wieder vor, daß da irgendein OEM ein paar Funktionen in der Hardware einspart, um etwas Geld zu sparen... aber in meinem Fall hatte der IT Dienstleister seinem Endkungen 12-13 Jahre alte Hardware untergejubelt und die dann 12-13 Jahre alte Karte kann dann effektiv kein TCP Chimney, wohingegen die Citrix-Typen sagen das wäre "best practice", auf die Hardware das auszulagern, was die Netzwerkkarte in Hardware ausführen kann, genauso wie das RSS. Nur gingen die Citrix Leute davon aus, daß sie Hardware mit Maintenance zur Verfügung hatten, also jünger als 5 oder 6 Jahre.
Bekanntestes Opfer ist die auf PC-Mainboards und ALLEN Esata Karten inexistente Fähigkeit zu ESATA Multiplexing... externe Gehäuse mit mehr als einer Festplatte und ESATA Anbindung gehen deshalb nicht, einfach weil die ganzen Hardwarehersteller da 10 Cent an Lizenzgebühren gespart hatten (Intel hat da ein Patent auf SATA Multiplexing).
Und wir hatten vor nicht mal einem Jahr das Problem, daß das TCP Chimney Offloading aktiv geschaltet war, weil die linke Hand des IT-Dienstleisters nicht wußte was die Rechte tut und beide der Meinung waren, daß sie keine Fehler gemacht hatten. Und es gab noch 6 weitere Hände wie bei Kaili, der indischen Göttin mit 8 Armen... wir doktorn da im 1st und 2nd Level Support mehr als ein Jahr daran herum und konnten das zumindestens mal reproduzieren wenn 20 User auf einem Citrix-Host aktiv waren.
Effektiv gab es einen daramatischen Zuwachs an Citrix Latenzen bis zu 1000 ms. Nachdem der Dienstleister einen Krisenmaanger bestellt hat und der dann mit ca. 20 Leute in einen Meetingraum gesperrt wurde hatten sie das Problem innerhalb von 2 Tagen gelöst und es war genau diese eine Einstellung... es kommt immer mal wieder vor, daß da irgendein OEM ein paar Funktionen in der Hardware einspart, um etwas Geld zu sparen... aber in meinem Fall hatte der IT Dienstleister seinem Endkungen 12-13 Jahre alte Hardware untergejubelt und die dann 12-13 Jahre alte Karte kann dann effektiv kein TCP Chimney, wohingegen die Citrix-Typen sagen das wäre "best practice", auf die Hardware das auszulagern, was die Netzwerkkarte in Hardware ausführen kann, genauso wie das RSS. Nur gingen die Citrix Leute davon aus, daß sie Hardware mit Maintenance zur Verfügung hatten, also jünger als 5 oder 6 Jahre.
Bekanntestes Opfer ist die auf PC-Mainboards und ALLEN Esata Karten inexistente Fähigkeit zu ESATA Multiplexing... externe Gehäuse mit mehr als einer Festplatte und ESATA Anbindung gehen deshalb nicht, einfach weil die ganzen Hardwarehersteller da 10 Cent an Lizenzgebühren gespart hatten (Intel hat da ein Patent auf SATA Multiplexing).
1
Moin NetzwerkDude,
nein, du musst nur genauer lesen, siehe blauer und nicht weisser Bereich des Screenshots. 😉
Ich kann das auf meinem Windows 10 2004 durchaus bestätigen, die TCP-Offload-Engine des Betriebssystems ist nicht mehr ansteuerbar!
Bei den vorherigen Windows konntest du den Status mit
abfragen und bekamst +- das folgende zu sehen.
Steuern konnte man das ganze mit
Bei meinem aktuellen Windows 10 ist davon aber nichts mehr zu sehen.
Und wenn man die oberen Befehle ausführen möchte so bekommen ich heute den folgenden Hinweis.
Nach meinem jetzigen Verständnis, sind damit alle Hardwareseitigen TCP-Offload Erweiterungen somit für die Katz, da diese nicht mehr angesprochen/angesteuert werden.
Meiner Meinung nach sollten diese dann auch aktiv durch die Anwender deaktiviert werden, bis die Netzwerkkarten Hersteller dies auch geschnallt haben und die Treiber entsprechend angepasst haben.
Das kann aber erfahrungsgemäss schon ein Jahrzehnt oder länger dauern (fast 3 Jahre sind ja schon vergangen). 😟
Grüsse aus BaWü
Alex
nein, du musst nur genauer lesen, siehe blauer und nicht weisser Bereich des Screenshots. 😉
Ich kann das auf meinem Windows 10 2004 durchaus bestätigen, die TCP-Offload-Engine des Betriebssystems ist nicht mehr ansteuerbar!
Bei den vorherigen Windows konntest du den Status mit
netsh int tcp show globalabfragen und bekamst +- das folgende zu sehen.
Steuern konnte man das ganze mit
netsh int tcp set global chimney=enabled
netsh int tcp set global chimney=disabledBei meinem aktuellen Windows 10 ist davon aber nichts mehr zu sehen.
Und wenn man die oberen Befehle ausführen möchte so bekommen ich heute den folgenden Hinweis.
Nach meinem jetzigen Verständnis, sind damit alle Hardwareseitigen TCP-Offload Erweiterungen somit für die Katz, da diese nicht mehr angesprochen/angesteuert werden.
Meiner Meinung nach sollten diese dann auch aktiv durch die Anwender deaktiviert werden, bis die Netzwerkkarten Hersteller dies auch geschnallt haben und die Treiber entsprechend angepasst haben.
Das kann aber erfahrungsgemäss schon ein Jahrzehnt oder länger dauern (fast 3 Jahre sind ja schon vergangen). 😟
Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Für mein Verständnis, sind damit sämtliche Hardwareseitigen TCP Offload Features der Netzwerkkarten damit für die Katz, da diese betriebssystemseitig (TCP Stack) nicht mehr unterstützt/angesprochen werden.
Für mein Verständnis, sind damit sämtliche Hardwareseitigen TCP Offload Features der Netzwerkkarten damit für die Katz, da diese betriebssystemseitig (TCP Stack) nicht mehr unterstützt/angesprochen werden.
Das ist falsch und steht ja im Grunde auch schon in deinem ersten Screenshot. Die TCP Offload Engine wurde mit 2003 eingeführt, hat aber neuere Entwicklungen nicht mehr mitgemacht sodas die Aktivierung der Offload Engine neuere Performanceverbesserungen wie SACK und CTCP quasi deaktiviert hat.
/Thomas
Moin Thomas,
was genau daran ist falsch?
Der TCP Stack ist ein Softwarebasierter Teil des Betriebssystems und das Offloading ist ein Feature von diesem, welches nun nicht mehr zur Verfügung steht. Wenn der TCP Stack des OS ein Feature alla RSS, RSC, VMQ & Co nicht unterstützt, dann ist meiner jetzigen Kenntnis nach, jedes Hardwarebasierte Feature nutzlos, da es von dem TCP Stack (OS (Windows oder Linuz oder ...)) nicht aktiv angesprochen/berücksichtigt wird.
Wenn es nicht so ist, dann bitte ich um eine etwas verständlichere Erklärung warum das nicht so sein sollte, danke.
Grüsse aus BaWü
Alex
was genau daran ist falsch?
Der TCP Stack ist ein Softwarebasierter Teil des Betriebssystems und das Offloading ist ein Feature von diesem, welches nun nicht mehr zur Verfügung steht. Wenn der TCP Stack des OS ein Feature alla RSS, RSC, VMQ & Co nicht unterstützt, dann ist meiner jetzigen Kenntnis nach, jedes Hardwarebasierte Feature nutzlos, da es von dem TCP Stack (OS (Windows oder Linuz oder ...)) nicht aktiv angesprochen/berücksichtigt wird.
Wenn es nicht so ist, dann bitte ich um eine etwas verständlichere Erklärung warum das nicht so sein sollte, danke.
Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Wenn es nicht so ist, dann bitte ich um eine etwas verständlichere Erklärung warum das nicht so sein sollte, danke.
Wenn es nicht so ist, dann bitte ich um eine etwas verständlichere Erklärung warum das nicht so sein sollte, danke.
Das einzige was entfernt wurde ist das Chimney Offload Feature, das war aber aus o.g. Gründen schon länger nicht mehr Best Practice.
/Thomas
Moin Thomas,
mit "Chimney Offload" ist so wie ich es bisher verstehe, die gesamte TCP-Offload-Engine des TCP-Stacks gemeint und nicht nur ein einzelnes Feature daraus. Die Bezeichnung ist etwas unglücklich, aber jede Dokumentation die ich bisher darüber gelesen habe, spricht für diese Annahme.
Hier ein, auch sprachlich interessanter Link zu diesem Thema.
https://support.microsoft.com/de-de/help/951037/information-about-the-tc ...
Wem der Schornstein auf den Keks geht, kann über den folgenden Link auch die englische Fassung lesen.
https://support.microsoft.com/en-us/help/951037/information-about-the-tc ...
„Chimney Offload“ bezeichnet heute somit kein bestimmtes Feature was die TCP-Offload-Engine bereitstellt.
„Chimney Offload“ ist in diesem Zusammenhang eher ein mittlerweile veralteter Oberbegriff / Kosename für die gesamte IP Offloadtechnologie und bezeichnet bei Microsoft in vielen Dokumenten eben die TCP-Offload-Engine als Ganzes. Die wiederum dafür verantwortlich war, die folgenden Hardware-Offload-Features richtig anzusteuern.
Eine Dokumentation die etwas anderes darstellt, habe ich noch nicht gefunden.
Wenn eine hast, dann rück diese bitte auch raus, danke. 🙃
Grüsse aus BaWü
Alex
mit "Chimney Offload" ist so wie ich es bisher verstehe, die gesamte TCP-Offload-Engine des TCP-Stacks gemeint und nicht nur ein einzelnes Feature daraus. Die Bezeichnung ist etwas unglücklich, aber jede Dokumentation die ich bisher darüber gelesen habe, spricht für diese Annahme.
Hier ein, auch sprachlich interessanter Link zu diesem Thema.
https://support.microsoft.com/de-de/help/951037/information-about-the-tc ...
Wem der Schornstein auf den Keks geht, kann über den folgenden Link auch die englische Fassung lesen.
https://support.microsoft.com/en-us/help/951037/information-about-the-tc ...
„Chimney Offload“ bezeichnet heute somit kein bestimmtes Feature was die TCP-Offload-Engine bereitstellt.
„Chimney Offload“ ist in diesem Zusammenhang eher ein mittlerweile veralteter Oberbegriff / Kosename für die gesamte IP Offloadtechnologie und bezeichnet bei Microsoft in vielen Dokumenten eben die TCP-Offload-Engine als Ganzes. Die wiederum dafür verantwortlich war, die folgenden Hardware-Offload-Features richtig anzusteuern.
Eine Dokumentation die etwas anderes darstellt, habe ich noch nicht gefunden.
Wenn eine hast, dann rück diese bitte auch raus, danke. 🙃
Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Eine Dokumentation die etwas anderes darstellt, habe ich noch nicht gefunden.
Wenn eine hast, dann rück diese bitte auch raus, danke. 🙃
Eine Dokumentation die etwas anderes darstellt, habe ich noch nicht gefunden.
Wenn eine hast, dann rück diese bitte auch raus, danke. 🙃
Die habe ich, aber "rausrücken" kann ich sie leider nicht da die Unterlagen nicht öffentlich sind. 🙃
Jedenfalls rät Microsoft schon länger von der Verwendung ab, da der TCP Stack effizienter ist als die TCP Offload Engine.
Moin Thomas,
Du bist aber auch gemein. 😥😪😭
Ja, das ist ein gutes Stichwort.
MS kann zwar jetzt nicht viel für die Hardwarenetzwerkkarten und deren vermurkste Treiber, aber Microsoft kann sich bei SD-NICs (vNIC) auf dem Hyper-V wohl kaum aus der Verantwortung ziehen. Hier sind die selbst für die vNICs und deren Treiber verantwortlich.
Und hier hat Microsoft, glaube ich, mindestens genau so viel Mist gebaut (oder von dieser blind kopiert), wie auch die Hardwarewelt.
Siehe:
Das sind die Erweiterten Optionen einer vNIC in einer VM mit Server 2019 auf einem HV-Node mit Server 2019.
Hier sind "hardwaretechnisch" alle Offload-Features witzigerweise noch aktiv, selbst das aller erste "IPv4 Checksum Offload" was auch gerne mal hardwareseitig als "Chimney Offload" bezeichnet wird. OK ... 😣😲?!?
Das alleine ist ja schon sehr witzig, aber das Witziger ist etwas ganz anderes.
OK, wenn wir von einem nativen Server sprechen, der die NICs auch in Hardware verbaut hat, dann habe ich für den Offload-Kram auch ein gewisses technisches Verständnis. Aber bei einer vNIC die vollständig Virtuell/"Software defind" ist, hört bei mir das Verständnis definitiv auf.
Was soll das eigentlich, wohin sollen die vNICs die offloaden, wenn keine reale Hardware dahinter steckt?
Jetzt mal auf gut deutsch gefragt.
Was soll der Hirnschiss?
@microsoft
Ist das jetzt wieder so eine "Hirn aus, Copy and Paste an" Aktion?
Beste Grüsse aus BaWü
Alex
Die habe ich, aber "rausrücken" kann ich sie leider nicht da die Unterlagen nicht öffentlich sind. 🙃
Du bist aber auch gemein. 😥😪😭
Jedenfalls rät Microsoft schon länger von der Verwendung ab, da der TCP Stack effizienter ist als die TCP Offload Engine.
Ja, das ist ein gutes Stichwort.
MS kann zwar jetzt nicht viel für die Hardwarenetzwerkkarten und deren vermurkste Treiber, aber Microsoft kann sich bei SD-NICs (vNIC) auf dem Hyper-V wohl kaum aus der Verantwortung ziehen. Hier sind die selbst für die vNICs und deren Treiber verantwortlich.
Und hier hat Microsoft, glaube ich, mindestens genau so viel Mist gebaut (oder von dieser blind kopiert), wie auch die Hardwarewelt.
Siehe:
Das sind die Erweiterten Optionen einer vNIC in einer VM mit Server 2019 auf einem HV-Node mit Server 2019.
Hier sind "hardwaretechnisch" alle Offload-Features witzigerweise noch aktiv, selbst das aller erste "IPv4 Checksum Offload" was auch gerne mal hardwareseitig als "Chimney Offload" bezeichnet wird. OK ... 😣😲?!?
Das alleine ist ja schon sehr witzig, aber das Witziger ist etwas ganz anderes.
OK, wenn wir von einem nativen Server sprechen, der die NICs auch in Hardware verbaut hat, dann habe ich für den Offload-Kram auch ein gewisses technisches Verständnis. Aber bei einer vNIC die vollständig Virtuell/"Software defind" ist, hört bei mir das Verständnis definitiv auf.
Was soll das eigentlich, wohin sollen die vNICs die offloaden, wenn keine reale Hardware dahinter steckt?
Jetzt mal auf gut deutsch gefragt.
Was soll der Hirnschiss?
@microsoft
Ist das jetzt wieder so eine "Hirn aus, Copy and Paste an" Aktion?
Beste Grüsse aus BaWü
Alex
Eine Hardware mit Offloading-Funktionalitäten brauch keine entsprechenden Softwarefeatures, APIs oder dergleichen. Wenn ein Treiber sowas anzeigt bei aktueller Hardware, dann ist das im Sinne der Usability zu verstehen. Manche Treiber haben so Zugriff auf die Hardware und man muss nicht ins Bios oder dergleichen.
Der Vergleich mit einem VSwitch ist unzulässig. Selbst wenn aus dem OS ein Feature entfernt ist, heißt da nicht zwangläufig, dass z. B. die Funktion aus den Bibliotheken, wie im Beipsiel, des Hyper-V entfernt ist.
Wenn die NIC eine Feature hat, musst das nciht für ein Hyper-V Switch als Gui oder CLI-Feature rausgeführt sein.
Um welche NICs und CNAs geht es denn eigentlich und was die der genaue Anwedungsfall.
Der Vergleich mit einem VSwitch ist unzulässig. Selbst wenn aus dem OS ein Feature entfernt ist, heißt da nicht zwangläufig, dass z. B. die Funktion aus den Bibliotheken, wie im Beipsiel, des Hyper-V entfernt ist.
Wenn die NIC eine Feature hat, musst das nciht für ein Hyper-V Switch als Gui oder CLI-Feature rausgeführt sein.
Um welche NICs und CNAs geht es denn eigentlich und was die der genaue Anwedungsfall.
Hi IT-Prof,
Das stimmt weder vorne noch hinten.
Der TCP-IP Stack läuft nicht auf der Hardware sondern ist ein Teil des Betriebssystems.
Die Prüfsummenberechnung ist wiederum ein Bestandteil des IPv4 Protokols, welches wiederum von dem TCP-IP Stacks des Betriebssystems zur Verfügung gestellt wird. Es gibt zwar auch NICs, insbesondere im iSCSI Bereich die den TCP-IP Stack auch quasi "onboard" haben, aber das ist ein ganz anderes Thema.
Somit muss der TCP-IP Stack des Betriebssystems als erstes entscheiden, ob er die Prüfsumme selber über die CPU des Rechners/Servers berechnen möchte, oder ob er diese Arbeit an die Netzwerkkarte auslagern möchte, was bisher über die besagte Offload Engine eben möglich war. Nun ist das nicht mehr gegeben und der TCP-IP Stack des Betriebssystems hat somit quasi keine Wahl, zwischen, mache ich es selbst oder lagere ich es aus. Für das letztere gibt es eben keine Unterstützung mehr, und da bringt es auch nichts, das die Hardware es noch kann. Das OS fordert diese Dienste nicht mehr an.
Im Storage Bereich ist es ähnlich, du kannst in dein SAN so viel Cache verbauen wie du möchtest.
Wenn das Storage von dem darüberliegenden Betriebssystem falsch erkannt/angesprochen wird, ist der ganze teure Cache einfach für die Katz, weil dieser im schlimmsten Fall gar nicht angesteuert wird. 😉
vSwitch ... wie kommst du jetzt auf das, in den Scrennshots oben ist eine vNIC und kein vSwitch abgebildet, somit ist der "Vergleich" schon durchaus realistisch.
😮
Das verstehe ich jetzt nicht so ganz. Eine vNIC ist eine vNIC und ein vSwitch ist ein vSwitch.
Über das letztere habe ich noch keine Silbe verloren.
Alle NICs die unter Windows laufen, und alle Anwendungsfälle die TCP-IP nutzen.
Es geht mir bei diesem Beitrag weniger darum eine Lösung zu finden als ein Problem zu verdeutlichen und auch um sicher zu gehen, dass ich bisher selber nichts falsch verstanden habe. 😉
Die kurzfristige Lösung habe ich schon erarbeitet.
An der langfristigen bin ich auch schon kräftig zugange. 😎
Grüsse aus BaWü
Alex
Eine Hardware mit Offloading-Funktionalitäten brauch keine entsprechenden Softwarefeatures, APIs oder dergleichen. Wenn ein Treiber sowas anzeigt bei aktueller Hardware, dann ist das im Sinne der Usability zu verstehen. Manche Treiber haben so Zugriff auf die Hardware und man muss nicht ins Bios oder dergleichen.
Das stimmt weder vorne noch hinten.
Der TCP-IP Stack läuft nicht auf der Hardware sondern ist ein Teil des Betriebssystems.
Die Prüfsummenberechnung ist wiederum ein Bestandteil des IPv4 Protokols, welches wiederum von dem TCP-IP Stacks des Betriebssystems zur Verfügung gestellt wird. Es gibt zwar auch NICs, insbesondere im iSCSI Bereich die den TCP-IP Stack auch quasi "onboard" haben, aber das ist ein ganz anderes Thema.
Somit muss der TCP-IP Stack des Betriebssystems als erstes entscheiden, ob er die Prüfsumme selber über die CPU des Rechners/Servers berechnen möchte, oder ob er diese Arbeit an die Netzwerkkarte auslagern möchte, was bisher über die besagte Offload Engine eben möglich war. Nun ist das nicht mehr gegeben und der TCP-IP Stack des Betriebssystems hat somit quasi keine Wahl, zwischen, mache ich es selbst oder lagere ich es aus. Für das letztere gibt es eben keine Unterstützung mehr, und da bringt es auch nichts, das die Hardware es noch kann. Das OS fordert diese Dienste nicht mehr an.
Im Storage Bereich ist es ähnlich, du kannst in dein SAN so viel Cache verbauen wie du möchtest.
Wenn das Storage von dem darüberliegenden Betriebssystem falsch erkannt/angesprochen wird, ist der ganze teure Cache einfach für die Katz, weil dieser im schlimmsten Fall gar nicht angesteuert wird. 😉
Der Vergleich mit einem VSwitch ist unzulässig. Selbst wenn aus dem OS ein Feature entfernt ist, heißt da nicht zwangläufig, dass z. B. die Funktion aus den Bibliotheken, wie im Beipsiel, des Hyper-V entfernt ist.
vSwitch ... wie kommst du jetzt auf das, in den Scrennshots oben ist eine vNIC und kein vSwitch abgebildet, somit ist der "Vergleich" schon durchaus realistisch.
Wenn die NIC eine Feature hat, musst das nciht für ein Hyper-V Switch als Gui oder CLI-Feature rausgeführt sein.
😮
Das verstehe ich jetzt nicht so ganz. Eine vNIC ist eine vNIC und ein vSwitch ist ein vSwitch.
Über das letztere habe ich noch keine Silbe verloren.
Um welche NICs und CNAs geht es denn eigentlich und was die der genaue Anwedungsfall.
Alle NICs die unter Windows laufen, und alle Anwendungsfälle die TCP-IP nutzen.
Es geht mir bei diesem Beitrag weniger darum eine Lösung zu finden als ein Problem zu verdeutlichen und auch um sicher zu gehen, dass ich bisher selber nichts falsch verstanden habe. 😉
Die kurzfristige Lösung habe ich schon erarbeitet.
An der langfristigen bin ich auch schon kräftig zugange. 😎
Grüsse aus BaWü
Alex
Ich denke Du hast nicht nur einiges falsch verstanden. Es scheint große Wissenslücken zu geben und Annahmen von denen Du dich nicht trennen kannst
Moin IT-Prof,
ich habe noch nie behauptet, dass das was ich verstanden habe auch so richtig sein muss!
Im Gegensatz zu dir, versuche ich das was ich weis, auch möglichst genau zu beschreiben und wenn es geht auch mit externen
Verweisen zu verknüpfen um zu belegen, dass ich es mir nicht vollständig selbst zusammengereimt habe.
Wenn du nun der Meinung bist, dass ich etwas falsch verstanden/interpretiert habe, so erwarte ich, vor allem von dir,
dass du dich professionell dazu äusserst und nicht nur mit einem neunmalklugen Spruch um dich wirfst. 🤨
Grüsse aus BaWü
Alex
Zitat von @142583:
Ich denke Du hast nicht nur einiges falsch verstanden. Es scheint große Wissenslücken zu geben und Annahmen von denen Du dich nicht trennen kannst
Ich denke Du hast nicht nur einiges falsch verstanden. Es scheint große Wissenslücken zu geben und Annahmen von denen Du dich nicht trennen kannst
ich habe noch nie behauptet, dass das was ich verstanden habe auch so richtig sein muss!
Im Gegensatz zu dir, versuche ich das was ich weis, auch möglichst genau zu beschreiben und wenn es geht auch mit externen
Verweisen zu verknüpfen um zu belegen, dass ich es mir nicht vollständig selbst zusammengereimt habe.
Wenn du nun der Meinung bist, dass ich etwas falsch verstanden/interpretiert habe, so erwarte ich, vor allem von dir,
dass du dich professionell dazu äusserst und nicht nur mit einem neunmalklugen Spruch um dich wirfst. 🤨
Grüsse aus BaWü
Alex
Dann befolge Mal deinen Rat selber.
Du bist völlig auf den Holzweg und jagst einen Geist.
Es war ja schon ein sonderbares Thema und die Information, dass Hardware die eine Beschleunigung in der Hardware hat, keine zusätzliche Software, auch keine Schnittstelle von OS benötigt, hast du bei Seite gewischt.
Dann kann man dir nicht helfen, wenn die die Funktion einer gesamten Industrie verdrehst.
Spätestens mit deinem Argument, des SAN-Caches, dass von der Software auf OS Ebene falsch erkannt werden kann, wirst Du als seltsamer Kautz wahrgenommen.
Man Spinne Mal diese Behauptung weiter, meine Programmierer hätten unzählige Fragen an dich.
Du hast augenscheinlich große Wissenslücken bist auch irgendwie nicht bereit falsches Wissen abzulegen und neues aufzunehmen.
Ein vNIC ist ein 1-Port vSwitch und ein 1-Port vSwitch ist ein 1-Port vNIC usw... Es ist erstmal alles Software.
Auf Basis der Implementierung kann es softwareseitige Beschleunigungen geben, die bei moderner Hardware die Beschleunigung in die Hardware verlegen. Dort sind optimierte Rechenwerke.
Das OS, mit oder ohne Treiber, guckt in einen schwarzes Loch, wobei im Idealfall optimierter Bitstream aus dem Loch kommt.
Ist der Bitstream z. B. zu Ende optimierter SAN Traffic, dann pappt das OS den Bitstream lediglich an seinen Speichercontroller und der Speichercontroller, der seitens der Software dem OS zur Verfügung steht spricht dann den Befehlssatz des verwendeten Storagesubs.
Will ich jetzt etwas sprechen, was die Hardware nicht kann, dass war bis vor einigen Jahren so, dann habe ich Offloader eingesetzt. Wichtig ist vielleicht zu wissen dass diese Offloader keinen Standard darstellen, sondern einen Sammelbegriff für sehr viele Techniken darstellen. TCP-Offload ist kein Standard. Lediglich die maximale Größe der Pakete ist standardisiert, vereinfacht gesagt.
Das entscheidende bei diesem Thema ist dass das Betriebssystem "nativen Traffic" bekommt. Wenn das so ist dann spielt es keine Rolle was aus dem Schwarzen Loch raus purzelt. Seien es TCP IP Pakete für iSCSI oder SCSI für FC HBA oder FcOE.
Storage arbeitet klassisch seriell. Ein Raid Controller arbeitet seriell. Wegen vieler Laufwerke, vieler Pfade zu den Laufwerken, teilweise mit Cache verbunden ist es spätestens bei der Übertragung durch IP nicht mehr sicherzustellen, dass die Pakete die im TCP-IP Transport sind in der gesendeten Reihenfolge eintreffen.
Hier setzt der Treiber an, der den Speichercontroller bedienen muss im OS und bei aktueller Hardware ist der eigentliche Workload auf den NIC/CNA und das OS bekommt nativen Traffic, zu Ende beschleunigt und optimiert.
Ein vSwitch kann z. B. auf vier 50 GBit Ports stehen. Diese sind mit geswitchter Fabric zu mehreren SAN-Controllern verbunden. Auf dem vSwitch steht ein Hypervisor der hunderte Warteschlangen über die Pfade verteilt für Storage Access und zugleich Millionen TCP Verbindungen für "normalen" IP Traffic.
Die VMs im Bauch des Hypervisor bekommen einen Software Speichercontroller und gucken in das schwarze Loch in der Erwartung, dass dort SCSI Pakete kommen die Summe das Wirken eines Storage abbilden. Die VM weiß nichts von Offloadern. Sie kann prinzipbedingt auch keinen Nutzen daraus ziehen.
Und so lange du glaubst dass alle NICs die unter Windows laufen, deiner merkwürdigen Vorstellungen zu unterwerfen sind... Werden wir dir hier nicht helfen können.
Du bist völlig auf den Holzweg und jagst einen Geist.
Es war ja schon ein sonderbares Thema und die Information, dass Hardware die eine Beschleunigung in der Hardware hat, keine zusätzliche Software, auch keine Schnittstelle von OS benötigt, hast du bei Seite gewischt.
Dann kann man dir nicht helfen, wenn die die Funktion einer gesamten Industrie verdrehst.
Spätestens mit deinem Argument, des SAN-Caches, dass von der Software auf OS Ebene falsch erkannt werden kann, wirst Du als seltsamer Kautz wahrgenommen.
Man Spinne Mal diese Behauptung weiter, meine Programmierer hätten unzählige Fragen an dich.
Du hast augenscheinlich große Wissenslücken bist auch irgendwie nicht bereit falsches Wissen abzulegen und neues aufzunehmen.
Ein vNIC ist ein 1-Port vSwitch und ein 1-Port vSwitch ist ein 1-Port vNIC usw... Es ist erstmal alles Software.
Auf Basis der Implementierung kann es softwareseitige Beschleunigungen geben, die bei moderner Hardware die Beschleunigung in die Hardware verlegen. Dort sind optimierte Rechenwerke.
Das OS, mit oder ohne Treiber, guckt in einen schwarzes Loch, wobei im Idealfall optimierter Bitstream aus dem Loch kommt.
Ist der Bitstream z. B. zu Ende optimierter SAN Traffic, dann pappt das OS den Bitstream lediglich an seinen Speichercontroller und der Speichercontroller, der seitens der Software dem OS zur Verfügung steht spricht dann den Befehlssatz des verwendeten Storagesubs.
Will ich jetzt etwas sprechen, was die Hardware nicht kann, dass war bis vor einigen Jahren so, dann habe ich Offloader eingesetzt. Wichtig ist vielleicht zu wissen dass diese Offloader keinen Standard darstellen, sondern einen Sammelbegriff für sehr viele Techniken darstellen. TCP-Offload ist kein Standard. Lediglich die maximale Größe der Pakete ist standardisiert, vereinfacht gesagt.
Das entscheidende bei diesem Thema ist dass das Betriebssystem "nativen Traffic" bekommt. Wenn das so ist dann spielt es keine Rolle was aus dem Schwarzen Loch raus purzelt. Seien es TCP IP Pakete für iSCSI oder SCSI für FC HBA oder FcOE.
Storage arbeitet klassisch seriell. Ein Raid Controller arbeitet seriell. Wegen vieler Laufwerke, vieler Pfade zu den Laufwerken, teilweise mit Cache verbunden ist es spätestens bei der Übertragung durch IP nicht mehr sicherzustellen, dass die Pakete die im TCP-IP Transport sind in der gesendeten Reihenfolge eintreffen.
Hier setzt der Treiber an, der den Speichercontroller bedienen muss im OS und bei aktueller Hardware ist der eigentliche Workload auf den NIC/CNA und das OS bekommt nativen Traffic, zu Ende beschleunigt und optimiert.
Ein vSwitch kann z. B. auf vier 50 GBit Ports stehen. Diese sind mit geswitchter Fabric zu mehreren SAN-Controllern verbunden. Auf dem vSwitch steht ein Hypervisor der hunderte Warteschlangen über die Pfade verteilt für Storage Access und zugleich Millionen TCP Verbindungen für "normalen" IP Traffic.
Die VMs im Bauch des Hypervisor bekommen einen Software Speichercontroller und gucken in das schwarze Loch in der Erwartung, dass dort SCSI Pakete kommen die Summe das Wirken eines Storage abbilden. Die VM weiß nichts von Offloadern. Sie kann prinzipbedingt auch keinen Nutzen daraus ziehen.
Und so lange du glaubst dass alle NICs die unter Windows laufen, deiner merkwürdigen Vorstellungen zu unterwerfen sind... Werden wir dir hier nicht helfen können.
1
Moin IT-Prof,
😲 ... 💔 🙃
Nein habe ich nicht, ich habe dem sehr wohl Beachtung geschenkt, nur glaube ich nicht gleich auch alles was ich lese.
Ich prüfe es auch gerne mal nach. 😉
Siehe meinen jüngsten Beitrag ...
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
Ich verdrehe diese nicht, ich versuche diese zu verstehen.
Und du bist momentan keine besonders professionelle Hilfe, wen ich das mal so anmerken darf.
Von dir vielleicht schon, aber ich fürchte hier hast du höchstens dir selber soeben ins nächste Knie geschossen.
Hier fängt es +- an ...
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
Hier siehst du übrigens auch meine Geheimwaffe. 😎
https://community.spiceworks.com/topic/post/8923297
oder hier
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
Aber ja, war ja dein eigenes Knie, deshalb nehme ich es dir auch nicht übel. 😀
Deinem letzten Satz stimme ich vollkommen zu. 👍👍👍
Dem davor ganz und gar nicht, eine NIC ist eine NIC und ein Switch ist ein Switch. 😉
Auf dem würde ich keineswegs widersprechen.
Das kommentiere ich jetzt besser nicht so wie ich es gerne möchte, sonst bekomme ich von den Forumadmins wieder einen auf den Deckel. 🙃
Das gilt auch für deine restlichen Bemerkungen.
Da du ja anscheinend ein "Offload-Prof" bist, würde ich dir dazu gerne noch die folgende Dokumentation ans Herz legen.
https://pdfs.semanticscholar.org/70cd/ec19f689049d85d9b421bdfeca19de4ca3 ...
Grüsse aus BaWü
Alex
Du bist völlig auf den Holzweg und jagst einen Geist.
😲 ... 💔 🙃
Es war ja schon ein sonderbares Thema und die Information, dass Hardware die eine Beschleunigung in der Hardware hat, keine zusätzliche Software, auch keine Schnittstelle von OS benötigt, hast du bei Seite gewischt.
Nein habe ich nicht, ich habe dem sehr wohl Beachtung geschenkt, nur glaube ich nicht gleich auch alles was ich lese.
Ich prüfe es auch gerne mal nach. 😉
Siehe meinen jüngsten Beitrag ...
https://community.spiceworks.com/topic/2282473-the-real-disaster-behind- ...
Dann kann man dir nicht helfen, wenn die die Funktion einer gesamten Industrie verdrehst.
Ich verdrehe diese nicht, ich versuche diese zu verstehen.
Und du bist momentan keine besonders professionelle Hilfe, wen ich das mal so anmerken darf.
Spätestens mit deinem Argument, des SAN-Caches, dass von der Software auf OS Ebene falsch erkannt werden kann, wirst Du als seltsamer Kautz wahrgenommen.
Von dir vielleicht schon, aber ich fürchte hier hast du höchstens dir selber soeben ins nächste Knie geschossen.
Hier fängt es +- an ...
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
Hier siehst du übrigens auch meine Geheimwaffe. 😎
https://community.spiceworks.com/topic/post/8923297
oder hier
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
Aber ja, war ja dein eigenes Knie, deshalb nehme ich es dir auch nicht übel. 😀
Ein vNIC ist ein 1-Port vSwitch und ein 1-Port vSwitch ist ein 1-Port vNIC usw... Es ist erstmal alles Software.
Deinem letzten Satz stimme ich vollkommen zu. 👍👍👍
Dem davor ganz und gar nicht, eine NIC ist eine NIC und ein Switch ist ein Switch. 😉
Auf Basis der Implementierung kann es softwareseitige Beschleunigungen geben, die bei moderner Hardware die Beschleunigung in die Hardware verlegen. Dort sind optimierte Rechenwerke.
Auf dem würde ich keineswegs widersprechen.
Das OS, mit oder ohne Treiber, guckt in einen schwarzes Loch, wobei im Idealfall optimierter Bitstream aus dem Loch kommt.
😮, was wie wohin gucken ... schwarzes Loch ... Bitstream ... und wieder ein Loch ... isch komm da jetzt nicht so ganz mit 😣🥴Ist der Bitstream z. B. zu Ende optimierter SAN Traffic, dann pappt das OS den Bitstream lediglich an seinen Speichercontroller und der Speichercontroller, der seitens der Software dem OS zur Verfügung steht spricht dann den Befehlssatz des verwendeten Storagesubs.
Das kommentiere ich jetzt besser nicht so wie ich es gerne möchte, sonst bekomme ich von den Forumadmins wieder einen auf den Deckel. 🙃
Das gilt auch für deine restlichen Bemerkungen.
Da du ja anscheinend ein "Offload-Prof" bist, würde ich dir dazu gerne noch die folgende Dokumentation ans Herz legen.
https://pdfs.semanticscholar.org/70cd/ec19f689049d85d9b421bdfeca19de4ca3 ...
Grüsse aus BaWü
Alex
Moin IT-Prof,
eines möchte ich dann aber doch noch gerne kommentieren, da du hier etwas wichtiges selbst feststellst, das ich ebenso sehe. 😉
👍👍👍
So, und jetzt kannst du mir bestimmt auch erklären, weshalb diese dann doch in der VM-NIC implementiert sind?
Und warum du diese Implementierung in demselben Post weiter oben verteidigst und auch noch versuchst diese zu rechtfertigen? 🤨
(Die oberen Screenshots, sind von einer vNIC aus einer VM und nicht von einem virtuellen Adapter auf dem HV Host, so wie du es wahrscheinlich interpretiert hast. 😉)
Grüsse aus BaWü
Alex
eines möchte ich dann aber doch noch gerne kommentieren, da du hier etwas wichtiges selbst feststellst, das ich ebenso sehe. 😉
Zitat von @142583:
Die VM weiß nichts von Offloadern. Sie kann prinzipbedingt auch keinen Nutzen daraus ziehen.
Die VM weiß nichts von Offloadern. Sie kann prinzipbedingt auch keinen Nutzen daraus ziehen.
👍👍👍
So, und jetzt kannst du mir bestimmt auch erklären, weshalb diese dann doch in der VM-NIC implementiert sind?
Und warum du diese Implementierung in demselben Post weiter oben verteidigst und auch noch versuchst diese zu rechtfertigen? 🤨
(Die oberen Screenshots, sind von einer vNIC aus einer VM und nicht von einem virtuellen Adapter auf dem HV Host, so wie du es wahrscheinlich interpretiert hast. 😉)
Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
So, und jetzt kannst du mir bestimmt auch erklären, weshalb diese dann doch in der VM-NIC implementiert sind?
Weil auch VMs diese Techniken unterstützen/aktivieren können oder eben nicht, hier von VMware z. B. für LSO ganz gut erklärt.So, und jetzt kannst du mir bestimmt auch erklären, weshalb diese dann doch in der VM-NIC implementiert sind?
P.S.: Es wäre schön wenn du diese passiv agressiven Zwinkersmileys weg lassen würdest. 😉😉😉
/Thomas
Moin Th0mKa,
bloss weil VMware eine Doku geschrieben hat, über eine Technologie die nicht von VMware stamm, glaube ich dieser noch lange nicht blind. Aber auch dann nicht, wenn es von VMware wäre.
Hat einer von euch schon mal darüber nachgedacht, ob das technisch überhaupt geht, und wenn ja, ob es dann auch Sinn macht?
Ich stelle euch jetzt eine einfache Frage.
Wie soll bitte die Hardware NIC, die Prüfsumme für ein Packet berechnen, welches von einer VM zu einer anderen VM über denselben vSwitch versendet wird?
Ich warne euch schon mal im Vorfeld vor, damit mir im Nachgang keiner sauer ist. Das ist eine Fangfrage!
Deshalb die Antwort darauf bitte ganz genau überlegen, danke.
Und wer diese Frage schon gemein findet, ich habe noch ganz viele mehr davon auf Lager.
Kompromissvorschlag, der eine oder andere lässt in Zukunft, die mehr als nur spekulativen Bemerkungen zu meiner Person weg und dann überlege ich mir das mit den Smileys, ob ich den einen oder anderen in Zukunft weglassen kann.
Du siehst an diesem Beitrag, dass ich das auch durchaus kann ;‑) (Das ist ein Emoticon), also würde ich mich freuen, wenn die andere Seite den Kompromiss auch eingehalten würde.
Grüsse aus BaWü
Alex
P.S. Bin schon sehr auf die Antworten gespannt, für einen erfahrenen Systemintegrator sollte diese eigentlich keine grosse Herausforderung sein.
Weil auch VMs diese Techniken unterstützen/aktivieren können oder eben nicht, hier von VMware z. B. für LSO ganz gut erklärt.
bloss weil VMware eine Doku geschrieben hat, über eine Technologie die nicht von VMware stamm, glaube ich dieser noch lange nicht blind. Aber auch dann nicht, wenn es von VMware wäre.
Hat einer von euch schon mal darüber nachgedacht, ob das technisch überhaupt geht, und wenn ja, ob es dann auch Sinn macht?
Ich stelle euch jetzt eine einfache Frage.
Wie soll bitte die Hardware NIC, die Prüfsumme für ein Packet berechnen, welches von einer VM zu einer anderen VM über denselben vSwitch versendet wird?
Ich warne euch schon mal im Vorfeld vor, damit mir im Nachgang keiner sauer ist. Das ist eine Fangfrage!
Deshalb die Antwort darauf bitte ganz genau überlegen, danke.
Und wer diese Frage schon gemein findet, ich habe noch ganz viele mehr davon auf Lager.
P.S.: Es wäre schön wenn du diese passiv agressiven Zwinkersmileys weg lassen würdest. 😉😉😉
Kompromissvorschlag, der eine oder andere lässt in Zukunft, die mehr als nur spekulativen Bemerkungen zu meiner Person weg und dann überlege ich mir das mit den Smileys, ob ich den einen oder anderen in Zukunft weglassen kann.
Du siehst an diesem Beitrag, dass ich das auch durchaus kann ;‑) (Das ist ein Emoticon), also würde ich mich freuen, wenn die andere Seite den Kompromiss auch eingehalten würde.
Grüsse aus BaWü
Alex
P.S. Bin schon sehr auf die Antworten gespannt, für einen erfahrenen Systemintegrator sollte diese eigentlich keine grosse Herausforderung sein.
Zitat von @MysticFoxDE:
bloss weil VMware eine Doku geschrieben hat, über eine Technologie die nicht von VMware stamm, glaube ich dieser noch lange nicht blind. Aber auch dann nicht, wenn es von VMware wäre.
Achso, haben die sich nur ausgedacht oder wie?bloss weil VMware eine Doku geschrieben hat, über eine Technologie die nicht von VMware stamm, glaube ich dieser noch lange nicht blind. Aber auch dann nicht, wenn es von VMware wäre.
Wie soll bitte die Hardware NIC, die Prüfsumme für ein Packet berechnen, welches von einer VM zu einer anderen VM über denselben vSwitch versendet wird?
Ich gehe davon aus das du die Doku der du nicht glaubst auch nicht gelesen hast? Sonst wäre die Frage wohl eher nicht aufgekommen.
Moin Th0mKa,
Ausgedacht nicht, aber stellenweise auch nicht viel nachgedacht.
Da gehst du aber von etwas falschem aus, ich habe die Doku sehr wohl gelesen und eine mehr als nur lustige Passage entdeckt, wo ich jetzt eigentlich davon ausgegangen bin, dass du mir diese unter die Nase reiben tust. Aber vielleicht hast du die Doku selbst nicht gelesen und oder nicht verstanden, wer weiss das schon.
Versuch dich doch bitte das nächste Mal, mehr an einer fachlicheren Antwort, als an einem neunmalklugen Spruch, danke.
Grüsse aus BaWü
Alex
Zitat von @Th0mKa:
Zitat von @MysticFoxDE:
bloss weil VMware eine Doku geschrieben hat, über eine Technologie die nicht von VMware stamm, glaube ich dieser noch lange nicht blind. Aber auch dann nicht, wenn es von VMware wäre.
Achso, haben die sich nur ausgedacht oder wie?bloss weil VMware eine Doku geschrieben hat, über eine Technologie die nicht von VMware stamm, glaube ich dieser noch lange nicht blind. Aber auch dann nicht, wenn es von VMware wäre.
Ausgedacht nicht, aber stellenweise auch nicht viel nachgedacht.
Wie soll bitte die Hardware NIC, die Prüfsumme für ein Packet berechnen, welches von einer VM zu einer anderen VM über denselben vSwitch versendet wird?
Ich gehe davon aus das du die Doku der du nicht glaubst auch nicht gelesen hast? Sonst wäre die Frage wohl eher nicht aufgekommen.Da gehst du aber von etwas falschem aus, ich habe die Doku sehr wohl gelesen und eine mehr als nur lustige Passage entdeckt, wo ich jetzt eigentlich davon ausgegangen bin, dass du mir diese unter die Nase reiben tust. Aber vielleicht hast du die Doku selbst nicht gelesen und oder nicht verstanden, wer weiss das schon.
Versuch dich doch bitte das nächste Mal, mehr an einer fachlicheren Antwort, als an einem neunmalklugen Spruch, danke.
Grüsse aus BaWü
Alex
Guckt man sich deine Links an, dann stellt man fest, dass man sich das sparen kann als Quelle oder Argumentationshilfe, deiner seits. Was willst du damit sagen?
Mal ne blöde Frage, die wirst du doch sicherlich beantworten können.
Wenn ich im ESXi einen Hardware FCoE oder FC Adapter habe und darauf eine VM, als Beispiel einen Server 2019 setze, der sein Storage im Windows Geräte Manager unter "Strorage Controllers" führt, wie kann der Server dann überhaupt den Cache des SANs sehen? Wie macht der Server oder der Treiber das? Und wie kann die VM diesen Cache, nach dem sie ihn sichtbar gemacht hat ignorieren? Der kann dann die die Drives direkt ansprechen, oder wie?
Mal angenommen, vergleichbare Config, hat einen Software FCoE Treiber und steht auf zwei Dual-Port CNAs mit jeweils 50 GBit und diese können z. B. RoCE2, iWarp oder InfiniBand, such dir was aus.... Wie kann ich nun den Bitstream noch Offloaden? Im Beispiel ist im RoCE eine Nvme oF SAN, dass SAN-Controller seitig über 64 GB Cache über zwei Controller verteilt verfügt. Der Server hat auch wieder seine virtualisierten Storage Controllers, die ein Laufwerk deiner Wahl halten.
Wie kann hier eine Offloadtechnik deiner Wahn Einfluss auf die Arbeitsweise und Funktionsweise nehmen? Wie ändern sich die Pakete die aus dem "schwarzen Loch" kommen und gehen? Der Treiber, weil er einen Parameter eingestellt bekommen hat, baut dann die Paket neu? Wo werden die Pakete gerechnet und wer informiert, die Teilnehmer, dass die Pakete nicht mehr so heißen und aussehen wie abgesendet?
Un erkläre es mir bitte so, dass ich im Wireshark gleich die Pakete ziehen kann, ich bin heute noch mal Online dies bezüglich. In dem Zuge kann ich dir dann auch 1-Port vSwitches mit 1-Port-vNics und in Kombination zeigen, zufällig laufen so hunderte Konfigs bei uns weltweit.
Was mich auch noch brennend interessiert ist, warum wir so viel Geld für Lossless Ethernet ausgegeben haben, wenn es anscheinend nur eine Treibersache ist, dass die Pakete alle in der richtigen Reihenfolge und vollständig und zeitnah kommen und gehen ins das schwarze Loch. Ich muss doch hier eine Verschwörung hinter vermuten?
Mal ne blöde Frage, die wirst du doch sicherlich beantworten können.
Wenn ich im ESXi einen Hardware FCoE oder FC Adapter habe und darauf eine VM, als Beispiel einen Server 2019 setze, der sein Storage im Windows Geräte Manager unter "Strorage Controllers" führt, wie kann der Server dann überhaupt den Cache des SANs sehen? Wie macht der Server oder der Treiber das? Und wie kann die VM diesen Cache, nach dem sie ihn sichtbar gemacht hat ignorieren? Der kann dann die die Drives direkt ansprechen, oder wie?
Mal angenommen, vergleichbare Config, hat einen Software FCoE Treiber und steht auf zwei Dual-Port CNAs mit jeweils 50 GBit und diese können z. B. RoCE2, iWarp oder InfiniBand, such dir was aus.... Wie kann ich nun den Bitstream noch Offloaden? Im Beispiel ist im RoCE eine Nvme oF SAN, dass SAN-Controller seitig über 64 GB Cache über zwei Controller verteilt verfügt. Der Server hat auch wieder seine virtualisierten Storage Controllers, die ein Laufwerk deiner Wahl halten.
Wie kann hier eine Offloadtechnik deiner Wahn Einfluss auf die Arbeitsweise und Funktionsweise nehmen? Wie ändern sich die Pakete die aus dem "schwarzen Loch" kommen und gehen? Der Treiber, weil er einen Parameter eingestellt bekommen hat, baut dann die Paket neu? Wo werden die Pakete gerechnet und wer informiert, die Teilnehmer, dass die Pakete nicht mehr so heißen und aussehen wie abgesendet?
Un erkläre es mir bitte so, dass ich im Wireshark gleich die Pakete ziehen kann, ich bin heute noch mal Online dies bezüglich. In dem Zuge kann ich dir dann auch 1-Port vSwitches mit 1-Port-vNics und in Kombination zeigen, zufällig laufen so hunderte Konfigs bei uns weltweit.
Was mich auch noch brennend interessiert ist, warum wir so viel Geld für Lossless Ethernet ausgegeben haben, wenn es anscheinend nur eine Treibersache ist, dass die Pakete alle in der richtigen Reihenfolge und vollständig und zeitnah kommen und gehen ins das schwarze Loch. Ich muss doch hier eine Verschwörung hinter vermuten?
Moin IT-Prof
Lese auch die Antworten der Anderen, dann wirst du vielleicht auch von alleine dahinterkommen.
Wenn der Hypervisor den Cache des SANs selbst nicht richtig erkennen kann, so wird er diese Information auch an die VM weitergeben. Und diese markiert die entsprechende LUN als „uncached“ und feuert folgend auch sämtliche IOs mit einen Uncaching Flag ab, an welches sich das SAN zum Schluss auch hält. Und wenn du mir nicht glaubst, dann versuche es doch einfach mal selbst aus. Diskspd sollte einem IT-Prof ja ein Begriff sein. Solltest du bei dem Erstellen des Testszenarios oder den Parameter Hilfe benötigen, so sag einfach kurz Bescheid.
Ein CNA muss nichts offloaden.
War das jetzt die Gegenfangfrage?
Die Frage ist zwar etwas konfus gestellt, aber ich versuche dir diese dennoch zu beantworten.
Als erstes muss das SAN die entsprechende LUN auch richtig „ausweisen“, sprich als „gecacht/gepuffert“ kennzeichnen und bereits hier haben diverse Hersteller Probleme damit. Als nächstes muss die Verbindungstopologie bis zum Endziel dieses Cache-Flag auch verarbeiten und weiterreichen können. Wenn alle ihre Hausaufgaben richtige gemacht haben, so weis am Ende deine VM sehr wohl ganz genau, ob deren eigene „vDisk“ auf einer LUN liegt, die gepuffert ist oder nicht. Wenn die Hausaufgaben durch die beteiligten Hersteller (SAN/HBA/CNA/OS & Co.) nicht richtig gemacht wurden, so wird der Cache in den meisten fällen entweder nicht richtig oder gar nicht angesprochen.
Du vermischst mir hier zu viele Dinge ineinander, kannst du die Frage bitte verständlicher gestalten, danke.
In dem diese zwischendurch, durch ein Wurmloch flitzen.
Sorry, aber ich kann dir mit dem Schwarzen Loch einfach nicht folgen.
Mein lieber Scholli, du hopfst aber echt ohne Vorwarnung von links nach rechts.
Folgendes Erklärungsbeispiel ist für das Senden gedacht, für die Empfangsrichtung kann ich es dir bei Bedarf aber auch gerne detailliert erklären.
Nein die NIC baut die Pakete nicht neu auf, wobei ergänzen hier eher der richtigere Ausdruck wäre. Das muss sie gar nicht mehr. Durch den „no Offload“ Flag, weiss hier weniger die NIC selbst Bescheid, das jetzt ein Packet kommt wo die Prüfsumme noch zu berechnen und ans Paket anzuhängen ist, als das der TCP-IP-Kernel des Betriebssystems schon im Vorfeld informiert ist, dass die NIC es nicht kann oder will und dieser daher die Arbeit gleich selbst erledigen kann.
Kannst du dich bitte etwas genauer ausdrücken, ich verstehe hier leider mal wieder nur Bahnhof. 😵
Du kannst per Wireshark den Datenverkehr zwischen dem IP-Stack und der Netzwerkkarte selbst mitschneiden, aha, zeigst du mir bitte wie das gehen soll und ich bin mir jetzt zu 100% sicher, dass ich an dieser Stelle jetzt nicht der einzige Interessent für diese Information bin.
Und bevor du dich jetzt an einer Antwort verkünstelst, das geht nicht. Dafür ist Wireshark auch gar nicht ausgelegt. Mit Wireshark siehst du lediglich das fertige Packet welches schlussendlich die NIC verlässt oder in diese gerade rein kommt. Die Verarbeitungsschritte in der NIC und im IP-Kernel und die Kommunikation dazwischen, kannst du mit Wireshark (leider) nicht analysieren.
Ich empfehle dir dringend von einem schwarzen Loch auch ein Wurmloch umzusteigen!
im Gegensatz zu einem schwarzen Loch, ist es bei einem Wurmloch durchaus möglich, dass Pakete gehen und vor allem auch kommen können. Bei einem schwarzen Loch können die Pakete gehen, kommen ganz sicher nicht.
Grüsse aus BaWü
Alex
Guckt man sich deine Links an, dann stellt man fest, dass man sich das sparen kann als Quelle oder Argumentationshilfe, deiner seits. Was willst du damit sagen?
Lese auch die Antworten der Anderen, dann wirst du vielleicht auch von alleine dahinterkommen.
Mal ne blöde Frage, die wirst du doch sicherlich beantworten können.
Wenn ich im ESXi einen Hardware FCoE oder FC Adapter habe und darauf eine VM, als Beispiel einen Server 2019 setze, der sein Storage im Windows Geräte Manager unter "Strorage Controllers" führt, wie kann der Server dann überhaupt den Cache des SANs sehen? Wie macht der Server oder der Treiber das? Und wie kann die VM diesen Cache, nach dem sie ihn sichtbar gemacht hat ignorieren? Der kann dann die die Drives direkt ansprechen, oder wie?
Wenn ich im ESXi einen Hardware FCoE oder FC Adapter habe und darauf eine VM, als Beispiel einen Server 2019 setze, der sein Storage im Windows Geräte Manager unter "Strorage Controllers" führt, wie kann der Server dann überhaupt den Cache des SANs sehen? Wie macht der Server oder der Treiber das? Und wie kann die VM diesen Cache, nach dem sie ihn sichtbar gemacht hat ignorieren? Der kann dann die die Drives direkt ansprechen, oder wie?
Wenn der Hypervisor den Cache des SANs selbst nicht richtig erkennen kann, so wird er diese Information auch an die VM weitergeben. Und diese markiert die entsprechende LUN als „uncached“ und feuert folgend auch sämtliche IOs mit einen Uncaching Flag ab, an welches sich das SAN zum Schluss auch hält. Und wenn du mir nicht glaubst, dann versuche es doch einfach mal selbst aus. Diskspd sollte einem IT-Prof ja ein Begriff sein. Solltest du bei dem Erstellen des Testszenarios oder den Parameter Hilfe benötigen, so sag einfach kurz Bescheid.
Mal angenommen, vergleichbare Config, hat einen Software FCoE Treiber und steht auf zwei Dual-Port CNAs mit jeweils 50 GBit und diese können z. B. RoCE2, iWarp oder InfiniBand, such dir was aus.... Wie kann ich nun den Bitstream noch Offloaden?
Ein CNA muss nichts offloaden.
War das jetzt die Gegenfangfrage?
Im Beispiel ist im RoCE eine Nvme oF SAN, dass SAN-Controller seitig über 64 GB Cache über zwei Controller verteilt verfügt. Der Server hat auch wieder seine virtualisierten Storage Controllers, die ein Laufwerk deiner Wahl halten.
Die Frage ist zwar etwas konfus gestellt, aber ich versuche dir diese dennoch zu beantworten.
Als erstes muss das SAN die entsprechende LUN auch richtig „ausweisen“, sprich als „gecacht/gepuffert“ kennzeichnen und bereits hier haben diverse Hersteller Probleme damit. Als nächstes muss die Verbindungstopologie bis zum Endziel dieses Cache-Flag auch verarbeiten und weiterreichen können. Wenn alle ihre Hausaufgaben richtige gemacht haben, so weis am Ende deine VM sehr wohl ganz genau, ob deren eigene „vDisk“ auf einer LUN liegt, die gepuffert ist oder nicht. Wenn die Hausaufgaben durch die beteiligten Hersteller (SAN/HBA/CNA/OS & Co.) nicht richtig gemacht wurden, so wird der Cache in den meisten fällen entweder nicht richtig oder gar nicht angesprochen.
Wie kann hier eine Offloadtechnik deiner Wahn Einfluss auf die Arbeitsweise und Funktionsweise nehmen?
Du vermischst mir hier zu viele Dinge ineinander, kannst du die Frage bitte verständlicher gestalten, danke.
Wie ändern sich die Pakete die aus dem "schwarzen Loch" kommen und gehen?
In dem diese zwischendurch, durch ein Wurmloch flitzen.
Sorry, aber ich kann dir mit dem Schwarzen Loch einfach nicht folgen.
Der Treiber, weil er einen Parameter eingestellt bekommen hat, baut dann die Paket neu?
Mein lieber Scholli, du hopfst aber echt ohne Vorwarnung von links nach rechts.
Folgendes Erklärungsbeispiel ist für das Senden gedacht, für die Empfangsrichtung kann ich es dir bei Bedarf aber auch gerne detailliert erklären.
Nein die NIC baut die Pakete nicht neu auf, wobei ergänzen hier eher der richtigere Ausdruck wäre. Das muss sie gar nicht mehr. Durch den „no Offload“ Flag, weiss hier weniger die NIC selbst Bescheid, das jetzt ein Packet kommt wo die Prüfsumme noch zu berechnen und ans Paket anzuhängen ist, als das der TCP-IP-Kernel des Betriebssystems schon im Vorfeld informiert ist, dass die NIC es nicht kann oder will und dieser daher die Arbeit gleich selbst erledigen kann.
Wo werden die Pakete gerechnet und wer informiert, die Teilnehmer, dass die Pakete nicht mehr so heißen und aussehen wie abgesendet?
Kannst du dich bitte etwas genauer ausdrücken, ich verstehe hier leider mal wieder nur Bahnhof. 😵
Un erkläre es mir bitte so, dass ich im Wireshark gleich die Pakete ziehen kann, ich bin heute noch mal Online dies bezüglich. In dem Zuge kann ich dir dann auch 1-Port vSwitches mit 1-Port-vNics und in Kombination zeigen, zufällig laufen so hunderte Konfigs bei uns weltweit.
Du kannst per Wireshark den Datenverkehr zwischen dem IP-Stack und der Netzwerkkarte selbst mitschneiden, aha, zeigst du mir bitte wie das gehen soll und ich bin mir jetzt zu 100% sicher, dass ich an dieser Stelle jetzt nicht der einzige Interessent für diese Information bin.
Und bevor du dich jetzt an einer Antwort verkünstelst, das geht nicht. Dafür ist Wireshark auch gar nicht ausgelegt. Mit Wireshark siehst du lediglich das fertige Packet welches schlussendlich die NIC verlässt oder in diese gerade rein kommt. Die Verarbeitungsschritte in der NIC und im IP-Kernel und die Kommunikation dazwischen, kannst du mit Wireshark (leider) nicht analysieren.
Was mich auch noch brennend interessiert ist, warum wir so viel Geld für Lossless Ethernet ausgegeben haben, wenn es anscheinend nur eine Treibersache ist, dass die Pakete alle in der richtigen Reihenfolge und vollständig und zeitnah kommen und gehen ins das schwarze Loch. Ich muss doch hier eine Verschwörung hinter vermuten?
Ich empfehle dir dringend von einem schwarzen Loch auch ein Wurmloch umzusteigen!
im Gegensatz zu einem schwarzen Loch, ist es bei einem Wurmloch durchaus möglich, dass Pakete gehen und vor allem auch kommen können. Bei einem schwarzen Loch können die Pakete gehen, kommen ganz sicher nicht.
Grüsse aus BaWü
Alex
Okay, der Reihe nach.
Das SAN markiert das LUN als gepuffert oder nicht?
Wie ist diese Markierung definiert, da gibt es doch ein Whitepape bestimmt zu?
Das Hypervisor macht damit was? Das OS macht damit was?
Cache-Flag? Wie muss man sich das vorstellen, ein Platzhalter, der da ein Bit hat oder nicht, oder ein paar Bytes um den Speicher samt seiner Beschaffenheit zu beschreiben? Wie heißt das Flag zum Beispiel im iSCSI Befehlssatz?
Wie weiß eine VM über die VDisk mehr als über das gewählte Dateisystem und deren Organisation sich ermitteln lässt?
Gibt es da noch einen mystischen Zusatzlink?
Und wie sorgt eigentlich ein Server dafür, dass er die Blöcke unterhalb des Dateisystems nicht überschreibt, wenn noch ein anderer Server auf dem LUN arbeitet?
Wie bekomme ich ein OS deiner Wahl dazu den Cache des Controller zu umgehen? Ich möchte Mal was ausprobieren.
Außerdem dachte ich immer Diskspd drischt auf das Dateisystem ein. Wir nutzten das früher zum schätzen von SQL Themen.
Du kannst mit dem Tool auf Blockebene vordringen? Nun hänge ich voll an deinen Lippen.
Das SAN markiert das LUN als gepuffert oder nicht?
Wie ist diese Markierung definiert, da gibt es doch ein Whitepape bestimmt zu?
Das Hypervisor macht damit was? Das OS macht damit was?
Cache-Flag? Wie muss man sich das vorstellen, ein Platzhalter, der da ein Bit hat oder nicht, oder ein paar Bytes um den Speicher samt seiner Beschaffenheit zu beschreiben? Wie heißt das Flag zum Beispiel im iSCSI Befehlssatz?
Wie weiß eine VM über die VDisk mehr als über das gewählte Dateisystem und deren Organisation sich ermitteln lässt?
Gibt es da noch einen mystischen Zusatzlink?
Und wie sorgt eigentlich ein Server dafür, dass er die Blöcke unterhalb des Dateisystems nicht überschreibt, wenn noch ein anderer Server auf dem LUN arbeitet?
Wie bekomme ich ein OS deiner Wahl dazu den Cache des Controller zu umgehen? Ich möchte Mal was ausprobieren.
Außerdem dachte ich immer Diskspd drischt auf das Dateisystem ein. Wir nutzten das früher zum schätzen von SQL Themen.
Du kannst mit dem Tool auf Blockebene vordringen? Nun hänge ich voll an deinen Lippen.
Moin IT-Prof,
Gerne, aber ich merke mal sicherheitshalber an, dass wir damit das ursprüngliche Thema weitestgehend verlassen.
Ja, auch wenn es beim SAN noch eine Spur komplizierter ist, wie bei einer normalen HDD oder SSD die direkt per SATA oder SAS oder was auch immer am Server angebunden ist. Das SAN selbst muss den Drive-Cache richtig ansteuern, was vor allem bei SSD Bestückung extrem wichtig ist und auch den RAM Cache des Controllers bedienen, der dann schlussendlich als „Disk-Cache“ der bereitgestellten LUNs dient.
Ich versuche es mal vereinfacht an einer USB-Festplatte zu erklären.
Wenn du hergehst und eine USB-Festplatte das erste Mal in einen Rechner steckst, dann geht das Betriebssystem her und fragt das bisher unbekannte Gerät über standardisierte Verfahren (PnP), was bist du und was kannst du alles. Gemäss den erhaltenen Anworten versucht das Betriebssystem das Gerät richtig zuzuordnen und schaut nach ob es bereits den richtigen Treiber dafür hat. Wenn ja, dann initialisiert das OS die USB-Festplatte mithilfe des Treibers und der erhaltenen Informationen von der USB-Platte selbst. Wenn nun die USB-Festplatte die Fragen des OS beim initialisieren nur stellenweise oder falsch beantwortet, so wird diese vielleicht gar nicht oder nur fehlerhaft/unvollständig initialisiert.
Manchmal kann man bei solchen Erkennungsproblemen noch von Hand durch die Registry etwas nachhelfen, aber das ist eher als Workaround zu betrachten. Nachhaltig lösen kann so ein Problem nur der Hersteller, in dem er dem Gerät beibringt, die Fragen des Betriebssystems, bei der Erkennung richtig zu beantworten.
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl- ...
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl- ...
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl- ...
Der Hypervisor muss nun dafür sorgen, dass die definierenden Informationen der vDisk, die er der VM „bereitstellt“ nun wiederum den Eigenschaften entsprechen, die auch die reale LUN hat, auf der die vDisk schlussendlich liegt.
Du stellst aber Fragen, ich bin primär ein Systemintegrator und kein Treiberentwickler.
Den Flag gibt es und du kannst mit diesem die IOs auch "steuern", wie man am besten beim Diskspd sieht.
Wobei man hier echt mit den Cache Typen aufpassen muss.
Mit dem Parameter -Sb wird der Test unter der Berücksichtigung des Software Caches gestartet.
Damit ist jetzt keineswegs irgendein Hardware-Disk-Cache gemeint, sondern lediglich der Datacache des Betriebssystems, der im RAM dieses gehalten wird.
Mit -Su kann man die Nutzung des OS-Data-Caches unterdrücken.
Mit dem Parameter -Sw forderst du wiederum direct IO an (write-throught/read- throught) wobei nun der Disk-Cache des Ziels ignoriert wird, aber nicht der OS-Data-Cache.
Möchtest du sowohl ohne Disk-Cache als auch ohne Data-Cache testen, so musst du den Parameter -Suw benutzen, oder -Sh.
Details siehe hier.
https://github.com/Microsoft/diskspd/wiki/Command-line-and-parameters
s.O.
https://de.wikipedia.org/wiki/Schwarzes_Loch
auch gerne einen Zweiten
https://de.wikipedia.org/wiki/Wurmloch 🙃
Mit einem clusterfähigen Dateisystem und der entsprechenden Hardware oder auch Software (SDS) dahinter die dafür sorgt, dass sich keiner in die Quere kommt.
s.O.
Schon, und du kannst auch sehr genau einstellen, wie er auf das Dateisystem eindreschen soll.
Wie meinst du das mit der Blockebene?
Diskspd testet generell Blockbasiert, aber nicht nativ auf dem Datenträger, hier hängt noch das Dateisystem des Ziels dazwischen. Native Blocktests (ohne Filesystem) kannst du meines Wissens nach nur mit dem IOmeter machen.
Grüsse aus BaWü
Alex
Okay, der Reihe nach.
Gerne, aber ich merke mal sicherheitshalber an, dass wir damit das ursprüngliche Thema weitestgehend verlassen.
Das SAN markiert das LUN als gepuffert oder nicht?
Ja, auch wenn es beim SAN noch eine Spur komplizierter ist, wie bei einer normalen HDD oder SSD die direkt per SATA oder SAS oder was auch immer am Server angebunden ist. Das SAN selbst muss den Drive-Cache richtig ansteuern, was vor allem bei SSD Bestückung extrem wichtig ist und auch den RAM Cache des Controllers bedienen, der dann schlussendlich als „Disk-Cache“ der bereitgestellten LUNs dient.
Ich versuche es mal vereinfacht an einer USB-Festplatte zu erklären.
Wenn du hergehst und eine USB-Festplatte das erste Mal in einen Rechner steckst, dann geht das Betriebssystem her und fragt das bisher unbekannte Gerät über standardisierte Verfahren (PnP), was bist du und was kannst du alles. Gemäss den erhaltenen Anworten versucht das Betriebssystem das Gerät richtig zuzuordnen und schaut nach ob es bereits den richtigen Treiber dafür hat. Wenn ja, dann initialisiert das OS die USB-Festplatte mithilfe des Treibers und der erhaltenen Informationen von der USB-Platte selbst. Wenn nun die USB-Festplatte die Fragen des OS beim initialisieren nur stellenweise oder falsch beantwortet, so wird diese vielleicht gar nicht oder nur fehlerhaft/unvollständig initialisiert.
Manchmal kann man bei solchen Erkennungsproblemen noch von Hand durch die Registry etwas nachhelfen, aber das ist eher als Workaround zu betrachten. Nachhaltig lösen kann so ein Problem nur der Hersteller, in dem er dem Gerät beibringt, die Fragen des Betriebssystems, bei der Erkennung richtig zu beantworten.
Wie ist diese Markierung definiert, da gibt es doch ein Whitepape bestimmt zu?
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl- ...
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl- ...
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl- ...
Das Hypervisor macht damit was? Das OS macht damit was?
Der Hypervisor muss nun dafür sorgen, dass die definierenden Informationen der vDisk, die er der VM „bereitstellt“ nun wiederum den Eigenschaften entsprechen, die auch die reale LUN hat, auf der die vDisk schlussendlich liegt.
Cache-Flag? Wie muss man sich das vorstellen, ein Platzhalter, der da ein Bit hat oder nicht, oder ein paar Bytes um den Speicher samt seiner Beschaffenheit zu beschreiben? Wie heißt das Flag zum Beispiel im iSCSI Befehlssatz?
Du stellst aber Fragen, ich bin primär ein Systemintegrator und kein Treiberentwickler.
Den Flag gibt es und du kannst mit diesem die IOs auch "steuern", wie man am besten beim Diskspd sieht.
Wobei man hier echt mit den Cache Typen aufpassen muss.
Mit dem Parameter -Sb wird der Test unter der Berücksichtigung des Software Caches gestartet.
Damit ist jetzt keineswegs irgendein Hardware-Disk-Cache gemeint, sondern lediglich der Datacache des Betriebssystems, der im RAM dieses gehalten wird.
Mit -Su kann man die Nutzung des OS-Data-Caches unterdrücken.
Mit dem Parameter -Sw forderst du wiederum direct IO an (write-throught/read- throught) wobei nun der Disk-Cache des Ziels ignoriert wird, aber nicht der OS-Data-Cache.
Möchtest du sowohl ohne Disk-Cache als auch ohne Data-Cache testen, so musst du den Parameter -Suw benutzen, oder -Sh.
Details siehe hier.
https://github.com/Microsoft/diskspd/wiki/Command-line-and-parameters
Wie weiß eine VM über die VDisk mehr als über das gewählte Dateisystem und deren Organisation sich ermitteln lässt?
s.O.
Gibt es da noch einen mystischen Zusatzlink?
https://de.wikipedia.org/wiki/Schwarzes_Loch
auch gerne einen Zweiten
https://de.wikipedia.org/wiki/Wurmloch 🙃
Und wie sorgt eigentlich ein Server dafür, dass er die Blöcke unterhalb des Dateisystems nicht überschreibt, wenn noch ein anderer Server auf dem LUN arbeitet?
Mit einem clusterfähigen Dateisystem und der entsprechenden Hardware oder auch Software (SDS) dahinter die dafür sorgt, dass sich keiner in die Quere kommt.
Wie bekomme ich ein OS deiner Wahl dazu den Cache des Controller zu umgehen? Ich möchte Mal was ausprobieren.
s.O.
Außerdem dachte ich immer Diskspd drischt auf das Dateisystem ein. Wir nutzten das früher zum schätzen von SQL Themen.
Schon, und du kannst auch sehr genau einstellen, wie er auf das Dateisystem eindreschen soll.
Du kannst mit dem Tool auf Blockebene vordringen? Nun hänge ich voll an deinen Lippen.
Wie meinst du das mit der Blockebene?
Diskspd testet generell Blockbasiert, aber nicht nativ auf dem Datenträger, hier hängt noch das Dateisystem des Ziels dazwischen. Native Blocktests (ohne Filesystem) kannst du meines Wissens nach nur mit dem IOmeter machen.
Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
„Chimney Offload“ bezeichnet heute somit kein bestimmtes Feature was die TCP-Offload-Engine bereitstellt.
„Chimney Offload“ ist in diesem Zusammenhang eher ein mittlerweile veralteter Oberbegriff / Kosename für die gesamte IP Offloadtechnologie und bezeichnet bei Microsoft in vielen Dokumenten eben die TCP-Offload-Engine als Ganzes. Die wiederum dafür verantwortlich war, die folgenden Hardware-Offload-Features richtig anzusteuern.
„Chimney Offload“ bezeichnet heute somit kein bestimmtes Feature was die TCP-Offload-Engine bereitstellt.
„Chimney Offload“ ist in diesem Zusammenhang eher ein mittlerweile veralteter Oberbegriff / Kosename für die gesamte IP Offloadtechnologie und bezeichnet bei Microsoft in vielen Dokumenten eben die TCP-Offload-Engine als Ganzes. Die wiederum dafür verantwortlich war, die folgenden Hardware-Offload-Features richtig anzusteuern.
Chimney Offload ist die von Microsoft einst präferierte Bezeichnung für TOE, also synonym, soweit wir von der Windows-Welt sprechen.
"TCP Offload Engine" mag ein semantisch weit gefasster Begriff sein, aber sein üblicher Gebrauch (etwa in dem englischsprachigen Wikipedia-Artikel, wie dort an den Ausführungen zur Historie und den Verweisen auf die Patente ersichtlich) erstreckt sich auf die TCP Offload Engine, wie sie von MS als Chimney Offload implementiert wurde. Und diese TOE bzw. Chimney Offload ist ein veraltetes Set von Offloading-Features, das weder auf Hardware- noch auf Windows-Seite heute Verwendung findet.
Das bedeutet nicht, dass die unterstützen granularen Offload-Features aus deinen Screenshots nicht unterstützt würden. Wenn diese aktiviert sind, übernimmt die Netzwerkkarte diese Funktionen und der Treiber signalisiert sie als offloaded, was Windows natürlich auch weiterhin unterstützt, vgl: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddndis/n ...
Chimney Offload hingegen bedeutet, dass die gesamte Verarbeitung der Transportschicht einer bestehenden TCP-Verbindung an die Netzwerkkarte übergeben wird. Das unterschiedliche Verhalten ist auch in Wireshark verifizierbar, entsprechende Hardware vorausgesetzt, weil WinPcap einerseits z.B. "falsche" Checksums sieht und andererseits im Fall von Chimney Offload überhaupt keine TCP-Verbindung.
Die Verwaltung des Chimney Offloads bedeutet selbst einen Overhead, sodass es überhaupt nur unter bestimmten Rahmenbedigungen genutzt wurde: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
Grüße
Richard
Moin Richard,
Ich bitte euch alle an dieser Stelle, mich nicht mehr von der zum Teil sehr grauen Theorie zu überzeugen, das ist vergebene Liebesmühe. Ich lasse mich gerne von Fakten lenken und das bedeutet, dass ihr schon einen funktionierenden Gegenbeweis erbringen müsst, damit ich meine jetzige Meinung ändere.
Und dieses „offloaded“ kann man sehr einfach mit netstat -t überprüfen.
Siehe auch folgenden Beitrag von mir.
https://community.spiceworks.com/topic/post/8936851
Somit ist es eigentlich sehr einfach, mich nun vom Gegenteil zu überzeugen.
Einfach ein Windows nehmen bei welchem Cimney Offload nicht mehr in den globalen TCP Parametern auftaucht.
Müsste somit folgend aussehen.
Und dann mit netstat -t den aktuellen Verbindungsstatus beobachten. Wenn nun auch nur ein eine Verbindung mit „Offloaded“ kommt habt ihr mich sofort überzeugt.
Wenn alle Verbindungen die Ihr seht, nur mit „InHost“ gekennzeichnet werden, dann habe wahrscheinlich eher ich mit meiner Theorie recht.
Alle NICs in meinem Rechner unterstützen theoretisch das Offloading wie im folgenden Screenshot zu sehen ist.
Jedoch kann keine davon, aktuell auch nur ein einziges Paket bei mir offload verarbeiten.
Jetzt bin ich aber gespannt ...
Grüsse aus BaWü
Alex
Chimney Offload ist die von Microsoft einst präferierte Bezeichnung für TOE, also synonym, soweit wir von der Windows-Welt sprechen.
Auch, das weis ich, aber eben auch die Bezeichnung für die gesamte Offload Engine."TCP Offload Engine" mag ein semantisch weit gefasster Begriff sein, aber sein üblicher Gebrauch (etwa in dem englischsprachigen Wikipedia-Artikel, wie dort an den Ausführungen zur Historie und den Verweisen auf die Patente ersichtlich) erstreckt sich auf die TCP Offload Engine, wie sie von MS als Chimney Offload implementiert wurde. Und diese TOE bzw. Chimney Offload ist ein veraltetes Set von Offloading-Features, das weder auf Hardware- noch auf Windows-Seite heute Verwendung findet.
Ich habe schon die diversesten Artikel bei der Aufarbeitung dieses Themas durch. Es ist auch bei diesem nicht viel anders wie bei manch anderen Themen. Jeder schreibt das, was er theoretisch verstanden hat. Praktisch nachprüfen tun es leider die Wenigsten davon.Ich bitte euch alle an dieser Stelle, mich nicht mehr von der zum Teil sehr grauen Theorie zu überzeugen, das ist vergebene Liebesmühe. Ich lasse mich gerne von Fakten lenken und das bedeutet, dass ihr schon einen funktionierenden Gegenbeweis erbringen müsst, damit ich meine jetzige Meinung ändere.
Das bedeutet nicht, dass die unterstützen granularen Offload-Features aus deinen Screenshots nicht unterstützt würden.
Wie gesagt, ich bitte um einen Gegenbeweis.Wenn diese aktiviert sind, übernimmt die Netzwerkkarte diese Funktionen und der Treiber signalisiert sie als offloaded, was Windows natürlich auch weiterhin unterstützt
Und dieses „offloaded“ kann man sehr einfach mit netstat -t überprüfen.
Siehe auch folgenden Beitrag von mir.
https://community.spiceworks.com/topic/post/8936851
Somit ist es eigentlich sehr einfach, mich nun vom Gegenteil zu überzeugen.
Einfach ein Windows nehmen bei welchem Cimney Offload nicht mehr in den globalen TCP Parametern auftaucht.
Müsste somit folgend aussehen.
Und dann mit netstat -t den aktuellen Verbindungsstatus beobachten. Wenn nun auch nur ein eine Verbindung mit „Offloaded“ kommt habt ihr mich sofort überzeugt.
Wenn alle Verbindungen die Ihr seht, nur mit „InHost“ gekennzeichnet werden, dann habe wahrscheinlich eher ich mit meiner Theorie recht.
Alle NICs in meinem Rechner unterstützen theoretisch das Offloading wie im folgenden Screenshot zu sehen ist.
Jedoch kann keine davon, aktuell auch nur ein einziges Paket bei mir offload verarbeiten.
Jetzt bin ich aber gespannt ...
Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Ich bitte euch alle an dieser Stelle, mich nicht mehr von der zum Teil sehr grauen Theorie zu überzeugen, das ist vergebene Liebesmühe. Ich lasse mich gerne von Fakten lenken und das bedeutet, dass ihr schon einen funktionierenden Gegenbeweis erbringen müsst, damit ich meine jetzige Meinung ändere.
Ich bitte euch alle an dieser Stelle, mich nicht mehr von der zum Teil sehr grauen Theorie zu überzeugen, das ist vergebene Liebesmühe. Ich lasse mich gerne von Fakten lenken und das bedeutet, dass ihr schon einen funktionierenden Gegenbeweis erbringen müsst, damit ich meine jetzige Meinung ändere.
Das ist nun kein Ansporn. Ich führe gern auch Forendiskussionen zu interessanten Themen, kann aber gut damit leben, wenn Beteiligte sachlich falsche Meinungen haben.
Wenn diese aktiviert sind, übernimmt die Netzwerkkarte diese Funktionen und der Treiber signalisiert sie als offloaded, was Windows natürlich auch weiterhin unterstützt
Und dieses „offloaded“ kann man sehr einfach mit netstat -t überprüfen.
Nein, denn offload state von netstat -t bezieht sich auf Chimney Offload.
Alle NICs in meinem Rechner unterstützen theoretisch das Offloading wie im folgenden Screenshot zu sehen ist.
Nicht theoretisch, sondern es ist aktiv.
Jedoch kann keine davon, aktuell auch nur ein einziges Paket bei mir offload verarbeiten.
...mit Chimney Offload.
Du demonstrierst doch selbst damit, dass beides nichts miteinander zu tun hat. Wie oben schon gesagt - und ignoriert, kannst Du es mit Wireshark noch tiefergehend überprüfen. Kannst Du mir verraten, warum Wireshark überhaupt Hinweise wie "Incorrect, probably due to checksum offload" (oder so ähnlich) gibt für einen WinPcap-Mitschnitt, der mit Checksum-Offloading erstellt wurde, wenn doch Chimney-offloaded Verbindungen überhaupt nicht von WinPcap erfasst werden? Wenn es dasselbe wäre, würdest Du schlicht nichts sehen, sobald Offloading im Spiel ist.
Zitat von @MysticFoxDE:
Und dann mit netstat -t den aktuellen Verbindungsstatus beobachten. Wenn nun auch nur ein eine Verbindung mit „Offloaded“ kommt habt ihr mich sofort überzeugt.
Und dann mit netstat -t den aktuellen Verbindungsstatus beobachten. Wenn nun auch nur ein eine Verbindung mit „Offloaded“ kommt habt ihr mich sofort überzeugt.
Warum sollte das da erscheinen? Das bezieht sich ja auf die Chimney Offload Funktion die nicht mehr da ist.
/Thomas
Moin Zusammen,
ich bin mit meiner Meinung übrigens absolut nicht alleine.
Der folgende Artikel ist mittlerweile über 10 Jahre alt.
http://www.app-v.be/microsoft-server/tcp-offload-engine-toe-full-analys ...
Grüsse aus BaWü
Alex
ich bin mit meiner Meinung übrigens absolut nicht alleine.
Der folgende Artikel ist mittlerweile über 10 Jahre alt.
http://www.app-v.be/microsoft-server/tcp-offload-engine-toe-full-analys ...
Grüsse aus BaWü
Alex
Das die TCP Offload Engine problematisch war ist ja bekannt, dürfte neben ihren wenigen Einsatzszenarien ein weiterer Grund für das Entfernen aus dem OS sein.
/Thomas
Moin Thomas,
TCP (Checksum) Offload ist nicht gleich TCP Chimney Offload, das erste ist eher der Vorgänger vom zweiten.
Siehe dazu auch den folgenden zwar alten, aber dennoch sehr interessanten Artikel.
https://www.heise.de/newsticker/meldung/WinHEC-Mehr-Dampf-fuers-Netzwerk ...
"Die neue Version der vereinheitlichten Schnittstelle zwischen Betriebssystem und LAN-Kartentreiber (Network Device Interface Specification) bringt als Kerntechniken TCP Chimney Offload und RSS (Receive-Side Scaling) mit."
Und in Verbindung damit ist der folgende Satz auch sehr wichtig.
"Beim Offloading ist derzeit TCP Checksum Offload gebräuchlich: Die Netzwerkkarte erledigt die TCP-Prüfsummenberechnung in Hardware und nimmt so dem Host-Prozessor Rechenarbeit ab."
Somit hat "TCP Checksum Offload", laut diesem Artikel schon mal gar nichts direkt mit dem " TCP Chimney Offload" zu tun, sondern stellt eher eine eigenständige Verbesserung dar!
"Das bereits auf der vorvorigen WinHEC vorgestellte und zeitweise umstrittene TCP Chimney Offload geht aber weiter: Künftige, intelligente Netzwerkkarten sollen das Transmission Control Protocol (TCP) zwischen Öffnen und Schließen der Verbindung so autonom wie möglich erledigen."
Damit ist hier klar und deutlich gemeint, dass mit "TCP Chimney Offload" nicht nur eine Erweiterung ist, sondern eher eine ganze Engine die um weitere Funktionen ergänzt wird.
"Schornsteinähnlich ist an der Technik das Modell, die Daten von "oben" – also höheren Protokollschichten – schlicht in den Stack zu stopfen, der dann sehen muss, wie er sie nach "unten" an die Ethernet-Ebene weiterreicht. Bei nicht chimney-fähigen Karten respektive ihren Treibern fällt die TCP-Bearbeitung wieder an die Host-CPU zurück."
Insbesondere der letzte Satz, hat mir selbst bei einem Punkt auf die Sprünge geholfen und ich hoffe das er dem einen oder anderen hier auch die Augen öffnet.
Auch der folgende Artikel spricht über dieses Thema.
https://www.networkworld.com/article/2312386/microsoft-to-let-users-go-l ...
" the Microsoft Chimney Offload architecture, which enables hardware vendors to offload to hardware the work associated with TCP/IP data movement"
Bei diesem Artikel wird klar und deutlich auch von einer Architektur gesprochen, was eher einer Engine entspricht und nicht einem Einmalfeature.
https://www.networkcomputing.com/networking/picture-ethernet
"The company is designing a new architecture, called Chimney, in its next-generation Windows server product that will support TCP/IP offload to dedicated server chips."
Auch hier wird von Architektur gesprochen.
Grüsse aus BaWü
Alex
Das die TCP Offload Engine problematisch war ist ja bekannt, dürfte neben ihren wenigen Einsatzszenarien ein weiterer Grund für das Entfernen aus dem OS sein.
TCP (Checksum) Offload ist nicht gleich TCP Chimney Offload, das erste ist eher der Vorgänger vom zweiten.
Siehe dazu auch den folgenden zwar alten, aber dennoch sehr interessanten Artikel.
https://www.heise.de/newsticker/meldung/WinHEC-Mehr-Dampf-fuers-Netzwerk ...
"Die neue Version der vereinheitlichten Schnittstelle zwischen Betriebssystem und LAN-Kartentreiber (Network Device Interface Specification) bringt als Kerntechniken TCP Chimney Offload und RSS (Receive-Side Scaling) mit."
Und in Verbindung damit ist der folgende Satz auch sehr wichtig.
"Beim Offloading ist derzeit TCP Checksum Offload gebräuchlich: Die Netzwerkkarte erledigt die TCP-Prüfsummenberechnung in Hardware und nimmt so dem Host-Prozessor Rechenarbeit ab."
Somit hat "TCP Checksum Offload", laut diesem Artikel schon mal gar nichts direkt mit dem " TCP Chimney Offload" zu tun, sondern stellt eher eine eigenständige Verbesserung dar!
"Das bereits auf der vorvorigen WinHEC vorgestellte und zeitweise umstrittene TCP Chimney Offload geht aber weiter: Künftige, intelligente Netzwerkkarten sollen das Transmission Control Protocol (TCP) zwischen Öffnen und Schließen der Verbindung so autonom wie möglich erledigen."
Damit ist hier klar und deutlich gemeint, dass mit "TCP Chimney Offload" nicht nur eine Erweiterung ist, sondern eher eine ganze Engine die um weitere Funktionen ergänzt wird.
"Schornsteinähnlich ist an der Technik das Modell, die Daten von "oben" – also höheren Protokollschichten – schlicht in den Stack zu stopfen, der dann sehen muss, wie er sie nach "unten" an die Ethernet-Ebene weiterreicht. Bei nicht chimney-fähigen Karten respektive ihren Treibern fällt die TCP-Bearbeitung wieder an die Host-CPU zurück."
Insbesondere der letzte Satz, hat mir selbst bei einem Punkt auf die Sprünge geholfen und ich hoffe das er dem einen oder anderen hier auch die Augen öffnet.
Auch der folgende Artikel spricht über dieses Thema.
https://www.networkworld.com/article/2312386/microsoft-to-let-users-go-l ...
" the Microsoft Chimney Offload architecture, which enables hardware vendors to offload to hardware the work associated with TCP/IP data movement"
Bei diesem Artikel wird klar und deutlich auch von einer Architektur gesprochen, was eher einer Engine entspricht und nicht einem Einmalfeature.
https://www.networkcomputing.com/networking/picture-ethernet
"The company is designing a new architecture, called Chimney, in its next-generation Windows server product that will support TCP/IP offload to dedicated server chips."
Auch hier wird von Architektur gesprochen.
Grüsse aus BaWü
Alex
Um mal auf den Ursprung des Threads zurückzukommen, das Thema ist immer noch diese?
Wenn ja halte ich diese Aussage immer noch für falsch.
/Thomas
Für mein Verständnis, sind damit sämtliche Hardwareseitigen TCP Offload Features der Netzwerkkarten damit für die Katz, da diese betriebssystemseitig (TCP Stack) nicht mehr unterstützt/angesprochen werden.
Wenn ja halte ich diese Aussage immer noch für falsch.
/Thomas
Moin Thomas,
Ja, ich bleibe bei der Aussage, aber ich möchte diese noch etwas verfeinern.
Die folgenden hardwareseitigen Features sind damit für die Katz und werden nicht mehr angesprochen.
Grüsse aus BaWü
Alex
Zitat von @Th0mKa:
Um mal auf den Ursprung des Threads zurückzukommen, das Thema ist immer noch diese?
Wenn ja halte ich diese Aussage immer noch für falsch.
Um mal auf den Ursprung des Threads zurückzukommen, das Thema ist immer noch diese?
Für mein Verständnis, sind damit sämtliche Hardwareseitigen TCP Offload Features der Netzwerkkarten damit für die Katz, da diese betriebssystemseitig (TCP Stack) nicht mehr unterstützt/angesprochen werden.
Wenn ja halte ich diese Aussage immer noch für falsch.
Ja, ich bleibe bei der Aussage, aber ich möchte diese noch etwas verfeinern.
Die folgenden hardwareseitigen Features sind damit für die Katz und werden nicht mehr angesprochen.
Grüsse aus BaWü
Alex
Na dann verfeiner mal, ich bin gespannt. Mich würde ja insbesondere eine Begründung für deine Aussage interessieren.
/Thomas
Moin Thomas,
dann lese einfach das was ich vorher geschrieben habe.
Für einen erfahren ITler, sollte das was ich bereits geschrieben habe genügen, um selbst darüber nachzudenken und nachforschen zu können.
Beleg du doch Mal bitte, das es so ist wie du es dir zusammenreihmst. 😉
Grüsse aus BaWü
Alex
Mich würde ja insbesondere eine Begründung für deine Aussage interessieren.
dann lese einfach das was ich vorher geschrieben habe.
Für einen erfahren ITler, sollte das was ich bereits geschrieben habe genügen, um selbst darüber nachzudenken und nachforschen zu können.
Beleg du doch Mal bitte, das es so ist wie du es dir zusammenreihmst. 😉
Grüsse aus BaWü
Alex
Moin C.R.S,
Nein ich habe die Aussage oben ganz sicher nicht ignoriert und auch schon dazugeschrieben, das Wireshark absolut nichts von offloaden mitschneiden kann, und bei dieser Aussage bleibe ich auch.
Das ist lediglich ein Hinweis, dass die Prüfsumme inkorrekt ist und das dieses Problem eventuell am checksum offload liegen könnte.
Wie gesagt es ist ein allgemeiner Hinweis, dass die Prüfsumme nicht richtig ist. Da steht mit keiner Silbe geschrieben, dass es definitiv am offload liegt. Das wirst du bei Wireshark niemals lesen, weil Wireshark es nicht bestimmen kann, ob dieser Fehler durch den TCP/OI-Stack verursacht wurde, oder ob die NIC die Prüfsumme durch den offload selbst verbockt hat.
Grüsse aus BaWü
Alex
Nachrag:
Das mit dem Wireshark und nicht dazwischen, muss ich eventuell revidieren, bitte Aussage mom. nicht bewerten, bin noch an der Nachprüfung.
Wie oben schon gesagt - und ignoriert, kannst Du es mit Wireshark noch tiefergehend überprüfen.
Nein ich habe die Aussage oben ganz sicher nicht ignoriert und auch schon dazugeschrieben, das Wireshark absolut nichts von offloaden mitschneiden kann, und bei dieser Aussage bleibe ich auch.
Kannst Du mir verraten, warum Wireshark überhaupt Hinweise wie "Incorrect, probably due to checksum offload" (oder so ähnlich) gibt für einen WinPcap-Mitschnitt, der mit Checksum-Offloading erstellt wurde, wenn doch Chimney-offloaded Verbindungen überhaupt nicht von WinPcap erfasst werden?
Das ist lediglich ein Hinweis, dass die Prüfsumme inkorrekt ist und das dieses Problem eventuell am checksum offload liegen könnte.
Wenn es dasselbe wäre, würdest Du schlicht nichts sehen, sobald Offloading im Spiel ist.
Wie gesagt es ist ein allgemeiner Hinweis, dass die Prüfsumme nicht richtig ist. Da steht mit keiner Silbe geschrieben, dass es definitiv am offload liegt. Das wirst du bei Wireshark niemals lesen, weil Wireshark es nicht bestimmen kann, ob dieser Fehler durch den TCP/OI-Stack verursacht wurde, oder ob die NIC die Prüfsumme durch den offload selbst verbockt hat.
Grüsse aus BaWü
Alex
Nachrag:
Das mit dem Wireshark und nicht dazwischen, muss ich eventuell revidieren, bitte Aussage mom. nicht bewerten, bin noch an der Nachprüfung.
Ne, so funktioniert das nicht. Du kannst nicht wilde Theorien aufstellen und dann zu anderen sagen sie sollen mal beweisen das das nicht so ist wie du dir das gerade ausgedacht hast. Das ist total lost... *Zwinkersmiley*
/Thomas
Dank des Internets ist niemand mehr mit seiner Meinung allein. Der verlinkte Artikel ist ja auch weitgehend (dem Überfliegen nach) richtig, nur vermischt er TOE und andere - tyischerweise als stateless Offloading bezeichnete - Features, die nichts miteinander zu tun haben.
Den Thread könnte man zu Humor verschieben. Indiana Jones und der Chimney Offload.
Also, weil so schönes Wetter ist: Natürlich kann Wireshark es nicht bestimmen, woran es liegt.
Aber Du kannst ja als guter Wissenschaftler eine einzelne Variable in einem Versuch ändern - z.B. Checksum-Offloading - und dann die Reaktion von Wireshark prüfen. Wenn Du das für beides machst, einmal Chimney Offload und ein andermal irgendein stateless Offloading wie Checksums, wirst Du feststellen, dass das Bild im Mitschnitt jeweils ein anderes ist, und es sich um zwei verschiedene Variablen handelt. Denn beides hat nichts miteinander zu tun.
Du bist offensichtlich gedanklich noch nicht mal in die Nähe eines praktischen Versuches gekommen, denn wie willst Du Chimney Offload positiv testen? Auf der gezeigten X710/T4? Die unterstützt kein TOE. Höchstwahrscheinlich hast Du überhaupt keine Karte mit diesem Feature in deinem Besitz. Diese "Architecture" war eine Totgeburt. Wenn Du eine Karte dafür suchst, dann schau mal unter zehn Jahre alten Broadcom-Chips.
Also, weil so schönes Wetter ist: Natürlich kann Wireshark es nicht bestimmen, woran es liegt.
Aber Du kannst ja als guter Wissenschaftler eine einzelne Variable in einem Versuch ändern - z.B. Checksum-Offloading - und dann die Reaktion von Wireshark prüfen. Wenn Du das für beides machst, einmal Chimney Offload und ein andermal irgendein stateless Offloading wie Checksums, wirst Du feststellen, dass das Bild im Mitschnitt jeweils ein anderes ist, und es sich um zwei verschiedene Variablen handelt. Denn beides hat nichts miteinander zu tun.
Du bist offensichtlich gedanklich noch nicht mal in die Nähe eines praktischen Versuches gekommen, denn wie willst Du Chimney Offload positiv testen? Auf der gezeigten X710/T4? Die unterstützt kein TOE. Höchstwahrscheinlich hast Du überhaupt keine Karte mit diesem Feature in deinem Besitz. Diese "Architecture" war eine Totgeburt. Wenn Du eine Karte dafür suchst, dann schau mal unter zehn Jahre alten Broadcom-Chips.
Moin Thomas,
Doch, doch, genau so funktioniert es normalerweise auch und es gibt dafür sogar ein passendes Wort welches sich Gegenbeweis nennt.
Du hast bisher jedoch nur Sprüche geklopft und noch keinen einzigen Beweis geliefert und es auch bisher nicht Mal wirklich versucht.
Raff, dass bitte ein für alle Mal. Mir geht es hier nicht um recht haben sondern um eine fundierte Aufarbeitung.
Ja, ich schiesse mit meinen eigenen Theorien manchmal daneben, vor allem wenn die Grundlagen, die zu diesen Theorien führen, selbst schon sehr Verwirrend sind. Und das ist mit diesem Thema durchaus der Fall.
Dieses Thema aufzuarbeiten ist eh schon schwer genug, weil ständig, je nach Schreiber und oder Hersteller, ein Begriff für unterschiedliche Sachverhalte/Funktionen verwendet wird, oder für dasselbe wiederum unterschiedliche Begriffe existieren. Da wirst du kirre beim Aufarbeiten und dann kommst du noch mit deinen mir, bisher absolut nutzlosen Sprüchen dazwischen.
Ich versuche wenigstens eine eigene Theorie zu entwickeln, die ich dann auch verstehe und auch vertreten kann, und jagen nicht ständig nur mit fremden durch die Gegend, die ich selbst nicht begründen kann. 😉
Etwas tiefgründig verstehen zu wollen und sich auf diesem Weg nicht von jedem Beliebigen nur durch einen Spruch abbringen zu lassen ist nicht lost, das ist konsequente Zielverfolgung.
Wenn du möchtest, dass ich deine Beiträge schätze, dann versuche mich nicht ständig unbegründet vom Ziel abzulenken, sondern belege mir einen Grund, so dass ich diesen auch verstehe und nachvollziehen kann. Dann wirst du schon sehen, dass ich den Kurs recht schnell auch von alleine wieder ändern kann.
Grüsse aus BaWü
Alex
Ne, so funktioniert das nicht.
Doch, doch, genau so funktioniert es normalerweise auch und es gibt dafür sogar ein passendes Wort welches sich Gegenbeweis nennt.
Du hast bisher jedoch nur Sprüche geklopft und noch keinen einzigen Beweis geliefert und es auch bisher nicht Mal wirklich versucht.
Raff, dass bitte ein für alle Mal. Mir geht es hier nicht um recht haben sondern um eine fundierte Aufarbeitung.
Ja, ich schiesse mit meinen eigenen Theorien manchmal daneben, vor allem wenn die Grundlagen, die zu diesen Theorien führen, selbst schon sehr Verwirrend sind. Und das ist mit diesem Thema durchaus der Fall.
Dieses Thema aufzuarbeiten ist eh schon schwer genug, weil ständig, je nach Schreiber und oder Hersteller, ein Begriff für unterschiedliche Sachverhalte/Funktionen verwendet wird, oder für dasselbe wiederum unterschiedliche Begriffe existieren. Da wirst du kirre beim Aufarbeiten und dann kommst du noch mit deinen mir, bisher absolut nutzlosen Sprüchen dazwischen.
Du kannst nicht wilde Theorien aufstellen und dann zu anderen sagen sie sollen mal beweisen das das nicht so ist wie du dir das gerade ausgedacht hast.
Ich versuche wenigstens eine eigene Theorie zu entwickeln, die ich dann auch verstehe und auch vertreten kann, und jagen nicht ständig nur mit fremden durch die Gegend, die ich selbst nicht begründen kann. 😉
Das ist total lost... *Zwinkersmiley*
Etwas tiefgründig verstehen zu wollen und sich auf diesem Weg nicht von jedem Beliebigen nur durch einen Spruch abbringen zu lassen ist nicht lost, das ist konsequente Zielverfolgung.
Wenn du möchtest, dass ich deine Beiträge schätze, dann versuche mich nicht ständig unbegründet vom Ziel abzulenken, sondern belege mir einen Grund, so dass ich diesen auch verstehe und nachvollziehen kann. Dann wirst du schon sehen, dass ich den Kurs recht schnell auch von alleine wieder ändern kann.
Grüsse aus BaWü
Alex
Moin C.R.S.,
wie schon oben erwähnt muss ich meine Aussagen bez. des Wireshark und des "nicht dazwischen" wahrscheinlich revidieren.
Hier habe ich so wie es aussieht, tatsächlich einen Denkfehler begangen.
Ich habe hierzu den folgenden interessanten Artikel gefunden.
https://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html
Die folgende Passage hat mich etwas zum Nachdenken bewogen.
"Checksum offloading often causes confusion as the network packets to be transmitted are handed over to Wireshark before the checksums are actually calculated. Wireshark gets these “empty” checksums and displays them as invalid, even though the packets will contain valid checksums when they leave the network hardware later."
Dieser Aussage nach snifft Wireshark doch direkt zwischen dem TCP-Stack und der Netzwerkkarte.
Klopft mich jetzt bitte nicht zu sehr für die folgende Aussage, aber ich dachte bisher, dass Wireshark so Richtung Sende- und Empfangspuffer der NICs snifft und dadurch die Pakete im Endzustand sieht. Aber fragt mich jetzt bitte nicht wie ich auf diese Idee gekommen bin, das kann ich selber nicht belegen.
Na ja, nun habe ich mich mich belegt, selbst belehrt. 🤪
Grüsse aus BaWü
Alex
Aber Du kannst ja als guter Wissenschaftler eine einzelne Variable in einem Versuch ändern - z.B. Checksum-Offloading - und dann die Reaktion von Wireshark prüfen. Wenn Du das für beides machst, einmal Chimney Offload und ein andermal irgendein stateless Offloading wie Checksums, wirst Du feststellen, dass das Bild im Mitschnitt jeweils ein anderes ist, und es sich um zwei verschiedene Variablen handelt. Denn beides hat nichts miteinander zu tun.
wie schon oben erwähnt muss ich meine Aussagen bez. des Wireshark und des "nicht dazwischen" wahrscheinlich revidieren.
Hier habe ich so wie es aussieht, tatsächlich einen Denkfehler begangen.
Ich habe hierzu den folgenden interessanten Artikel gefunden.
https://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html
Die folgende Passage hat mich etwas zum Nachdenken bewogen.
"Checksum offloading often causes confusion as the network packets to be transmitted are handed over to Wireshark before the checksums are actually calculated. Wireshark gets these “empty” checksums and displays them as invalid, even though the packets will contain valid checksums when they leave the network hardware later."
Dieser Aussage nach snifft Wireshark doch direkt zwischen dem TCP-Stack und der Netzwerkkarte.
Klopft mich jetzt bitte nicht zu sehr für die folgende Aussage, aber ich dachte bisher, dass Wireshark so Richtung Sende- und Empfangspuffer der NICs snifft und dadurch die Pakete im Endzustand sieht. Aber fragt mich jetzt bitte nicht wie ich auf diese Idee gekommen bin, das kann ich selber nicht belegen.
Na ja, nun habe ich mich mich belegt, selbst belehrt. 🤪
Grüsse aus BaWü
Alex
Moin C.R.S.,
diese Annahme möchte ich selbst nicht aussliessen, da es sehr mühselig ist herauszufinden, was mit was zusammenhängt und was wiederum nicht. Das ist ja mein Problem. Und ich finde im Netz bisher nichts brauchbares, wo diese Thematik halbwegs verständlich aufgearbeitet ist.
Grüsse aus BaWü
Alex
nur vermischt er TOE und andere - tyischerweise als stateless Offloading bezeichnete - Features, die nichts miteinander zu tun haben.
diese Annahme möchte ich selbst nicht aussliessen, da es sehr mühselig ist herauszufinden, was mit was zusammenhängt und was wiederum nicht. Das ist ja mein Problem. Und ich finde im Netz bisher nichts brauchbares, wo diese Thematik halbwegs verständlich aufgearbeitet ist.
Grüsse aus BaWü
Alex
Moin Zusammen,
folgend ein kleiner Zwischenstand.
Ich habe nun auf einem kleineren HV-Cluster (50 Anwendunguser) und auf einem etwas grösseren (120 Anwendungsuser) vollständig sämtliches Offloading auf den Hardware NICs deaktiviert und auch auf den wesentlichen VMs.
Das Ergebnis ist bei keinem der Systeme negativ, im Gegenteil, die Anwendungsperformance ist gestiegen und gleichzeitig ist die CPU Gesamtlast heruntergegangen. 😁
Es gibt einen ganz banalen Grund, weshalb ich von dem pauschalen Offloading absolut nichts halte.
Nehmen wir eine klassische Hypervisorumgebung, die so bestimmt tausendfach in Deutschen firmen verbaut ist. 2 HV-Nodes + SAN.
Auf diesen Umgebungen laufen unter Anderem DB-Server, Applikationsserver und auch RDS Umgebungen meist auf demselben Node.
Bei vielen DB-/Serverbasierten Applikationen, kommt meistens der Grossteil der Datenübermittlungen zwischen dem DB Server und den Applikationsservern zustande, vor allem wen RDS im Spiel ist, wird Richtung Client eh nur noch der Bildschirminhalt übertragen, der nur einen kleinen Bruchteil des Gesamtverkehrs der benutzen Applikation darstellt.
Der Grossteil des entstehenden Datenverkehrs der durch die Benutzung der Applikation bei einem solchen System verursacht wird, wird vollständig über die virtuelle Netzwerkumgebung (vNIC & vSwitch) abgehandelt und passiert somit niemals die physikalische Netzwerkkarte und kann daher auch gar nicht Offload verarbeitet werden!
Daher macht ein pauschales Offloading meiner Meinung nach auch absolut keinen Sinn. Wahrscheinlich ist das auch der Grund weshalb Microsoft diese Funktion auch nicht mehr unterstützt.
Grüsse aus BaWü
Alex
folgend ein kleiner Zwischenstand.
Ich habe nun auf einem kleineren HV-Cluster (50 Anwendunguser) und auf einem etwas grösseren (120 Anwendungsuser) vollständig sämtliches Offloading auf den Hardware NICs deaktiviert und auch auf den wesentlichen VMs.
Das Ergebnis ist bei keinem der Systeme negativ, im Gegenteil, die Anwendungsperformance ist gestiegen und gleichzeitig ist die CPU Gesamtlast heruntergegangen. 😁
Es gibt einen ganz banalen Grund, weshalb ich von dem pauschalen Offloading absolut nichts halte.
Nehmen wir eine klassische Hypervisorumgebung, die so bestimmt tausendfach in Deutschen firmen verbaut ist. 2 HV-Nodes + SAN.
Auf diesen Umgebungen laufen unter Anderem DB-Server, Applikationsserver und auch RDS Umgebungen meist auf demselben Node.
Bei vielen DB-/Serverbasierten Applikationen, kommt meistens der Grossteil der Datenübermittlungen zwischen dem DB Server und den Applikationsservern zustande, vor allem wen RDS im Spiel ist, wird Richtung Client eh nur noch der Bildschirminhalt übertragen, der nur einen kleinen Bruchteil des Gesamtverkehrs der benutzen Applikation darstellt.
Der Grossteil des entstehenden Datenverkehrs der durch die Benutzung der Applikation bei einem solchen System verursacht wird, wird vollständig über die virtuelle Netzwerkumgebung (vNIC & vSwitch) abgehandelt und passiert somit niemals die physikalische Netzwerkkarte und kann daher auch gar nicht Offload verarbeitet werden!
Daher macht ein pauschales Offloading meiner Meinung nach auch absolut keinen Sinn. Wahrscheinlich ist das auch der Grund weshalb Microsoft diese Funktion auch nicht mehr unterstützt.
Grüsse aus BaWü
Alex
