Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWünsch Dir wasWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Was bringen die TCP Offload Features der Hardware, wenn die TCP Offload Engine in Windows seit etwa 3 Jahren deaktiviert ist?

Mitglied: MysticFoxDE

MysticFoxDE (Level 1) - Jetzt verbinden

31.07.2020 um 09:19 Uhr, 941 Aufrufe, 46 Kommentare, 2 Danke

Moin Zusammen,

ich wurde gestern bei Spiceworks von einem anderen Forenuser auf das Folgende hingewiesen.

alquamar-tcp_offload - Klicke auf das Bild, um es zu vergrößern

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.

nic_tcp_offlod_features_01 - Klicke auf das Bild, um es zu vergrößern

nic_tcp_offlod_features_02 - Klicke auf das Bild, um es zu vergrößern

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
46 Antworten
Mitglied: IT-Prof
31.07.2020 um 09:26 Uhr
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.
Bitte warten ..
Mitglied: certifiedit.net
31.07.2020 um 09:35 Uhr
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...
Bitte warten ..
Mitglied: NetzwerkDude
31.07.2020, aktualisiert um 10:16 Uhr
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.
Bitte warten ..
Mitglied: MysticFoxDE
31.07.2020 um 10:18 Uhr
Moin NetzwerkDude,

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.

Es wurde schon beim 2012R2 Microsoft seitig deaktiviert und ist mit dem Server 2016 / Windows 10 1709 komplett herausgeflogen.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: NetzwerkDude
31.07.2020 um 10:21 Uhr
Also die von dir geposteten Links sagen eigentlich was anderes:
unbenannt - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: GrueneSosseMitSpeck
31.07.2020, aktualisiert um 11:02 Uhr
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).
Bitte warten ..
Mitglied: MysticFoxDE
31.07.2020, aktualisiert um 12:25 Uhr
Moin NetzwerkDude,

Zitat von NetzwerkDude:

Also die von dir geposteten Links sagen eigentlich was anderes:

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.
before - Klicke auf das Bild, um es zu vergrößern

Steuern konnte man das ganze mit

Bei meinem aktuellen Windows 10 ist davon aber nichts mehr zu sehen.
now - Klicke auf das Bild, um es zu vergrößern

Und wenn man die oberen Befehle ausführen möchte so bekommen ich heute den folgenden Hinweis.
no chimney - Klicke auf das Bild, um es zu vergrößern

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
Bitte warten ..
Mitglied: Th0mKa
31.07.2020 um 13:04 Uhr
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.

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
Bitte warten ..
Mitglied: MysticFoxDE
31.07.2020, aktualisiert um 14:15 Uhr
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
Bitte warten ..
Mitglied: Th0mKa
31.07.2020 um 15:04 Uhr
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.

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
Bitte warten ..
Mitglied: MysticFoxDE
31.07.2020, aktualisiert um 16:28 Uhr
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.

nic_tcp_offlod_features_01 - Klicke auf das Bild, um es zu vergrößern

nic_tcp_offlod_features_02 - Klicke auf das Bild, um es zu vergrößern

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
Bitte warten ..
Mitglied: Th0mKa
31.07.2020 um 16:30 Uhr
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. 🙃

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.
Bitte warten ..
Mitglied: MysticFoxDE
31.07.2020, aktualisiert um 17:28 Uhr
Moin Thomas,


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:
sd_nic_02 - Klicke auf das Bild, um es zu vergrößern
sd_nic_01 - Klicke auf das Bild, um es zu vergrößern

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
Bitte warten ..
Mitglied: IT-Prof
31.07.2020 um 18:16 Uhr
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.
Bitte warten ..
Mitglied: MysticFoxDE
31.07.2020 um 20:13 Uhr
Hi IT-Prof,

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
Bitte warten ..
Mitglied: IT-Prof
01.08.2020 um 00:25 Uhr
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
Bitte warten ..
Mitglied: MysticFoxDE
01.08.2020, aktualisiert um 09:01 Uhr
Moin IT-Prof,

Zitat von IT-Prof:

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
Bitte warten ..
Mitglied: IT-Prof
01.08.2020 um 10:03 Uhr
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.
Bitte warten ..
Mitglied: MysticFoxDE
01.08.2020 um 14:22 Uhr
Moin IT-Prof,


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

cache - Klicke auf das Bild, um es zu vergrößern

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
Bitte warten ..
Mitglied: MysticFoxDE
01.08.2020 um 14:53 Uhr
Moin IT-Prof,

eines möchte ich dann aber doch noch gerne kommentieren, da du hier etwas wichtiges selbst feststellst, das ich ebenso sehe. 😉

Zitat von IT-Prof:
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
Bitte warten ..
Mitglied: Th0mKa
01.08.2020 um 16:37 Uhr
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.

P.S.: Es wäre schön wenn du diese passiv agressiven Zwinkersmileys weg lassen würdest. 😉😉😉

/Thomas
Bitte warten ..
Mitglied: MysticFoxDE
01.08.2020, aktualisiert um 19:54 Uhr
Moin Th0mKa,
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.
Bitte warten ..
Mitglied: Th0mKa
01.08.2020 um 23:56 Uhr
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?

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.
Bitte warten ..
Mitglied: MysticFoxDE
02.08.2020 um 08:22 Uhr
Moin Th0mKa,

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?

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
Bitte warten ..
Mitglied: IT-Prof
02.08.2020 um 17:46 Uhr
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?
Bitte warten ..
Mitglied: MysticFoxDE
02.08.2020 um 21:19 Uhr
Moin IT-Prof
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 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
Bitte warten ..
Mitglied: IT-Prof
02.08.2020, aktualisiert um 21:49 Uhr
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.
Bitte warten ..
Mitglied: MysticFoxDE
03.08.2020, aktualisiert um 00:46 Uhr
Moin IT-Prof,

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
Bitte warten ..
Mitglied: C.R.S.
03.08.2020, aktualisiert um 02:19 Uhr
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 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
Bitte warten ..
Mitglied: MysticFoxDE
03.08.2020, aktualisiert um 10:01 Uhr
Moin Richard,

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.
now - Klicke auf das Bild, um es zu vergrößern

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.
offload state - Klicke auf das Bild, um es zu vergrößern

Jedoch kann keine davon, aktuell auch nur ein einziges Paket bei mir offload verarbeiten.
netstat - Klicke auf das Bild, um es zu vergrößern

Jetzt bin ich aber gespannt ...

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: C.R.S.
03.08.2020 um 11:14 Uhr
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.

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.
offload state - Klicke auf das Bild, um es zu vergrößern

Nicht theoretisch, sondern es ist aktiv.

Jedoch kann keine davon, aktuell auch nur ein einziges Paket bei mir offload verarbeiten.
netstat - Klicke auf das Bild, um es zu vergrößern

...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.
Bitte warten ..
Mitglied: Th0mKa
03.08.2020 um 11:59 Uhr
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.

Warum sollte das da erscheinen? Das bezieht sich ja auf die Chimney Offload Funktion die nicht mehr da ist.

/Thomas
Bitte warten ..
Mitglied: MysticFoxDE
03.08.2020, aktualisiert um 13:25 Uhr
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 ...

not alone - Klicke auf das Bild, um es zu vergrößern


Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: Th0mKa
03.08.2020 um 13:58 Uhr
Zitat von MysticFoxDE:

ich bin mit meiner Meinung übrigens absolut nicht alleine.

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
Bitte warten ..
Mitglied: MysticFoxDE
03.08.2020, aktualisiert um 14:48 Uhr
Moin Thomas,


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
Bitte warten ..
Mitglied: Th0mKa
03.08.2020 um 14:41 Uhr
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.

/Thomas
Bitte warten ..
Mitglied: MysticFoxDE
03.08.2020, aktualisiert um 14:55 Uhr
Moin Thomas,


Zitat von Th0mKa:

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.

sd_nic_01 - Klicke auf das Bild, um es zu vergrößern

sd_nic_02 - Klicke auf das Bild, um es zu vergrößern

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: Th0mKa
03.08.2020 um 15:04 Uhr
Zitat von MysticFoxDE:
Ja, ich bleibe bei der Aussage, aber ich möchte diese noch etwas verfeinern.

Na dann verfeiner mal, ich bin gespannt. Mich würde ja insbesondere eine Begründung für deine Aussage interessieren.

/Thomas
Bitte warten ..
Mitglied: MysticFoxDE
03.08.2020 um 17:23 Uhr
Moin Thomas,

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
Bitte warten ..
Mitglied: MysticFoxDE
03.08.2020, aktualisiert um 18:28 Uhr
Moin C.R.S,

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.
Bitte warten ..
Mitglied: Th0mKa
03.08.2020 um 19:26 Uhr
Zitat von MysticFoxDE:
Beleg du doch Mal bitte, das es so ist wie du es dir zusammenreihmst. 😉

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
Bitte warten ..
Mitglied: C.R.S.
03.08.2020 um 19:54 Uhr
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.
Bitte warten ..
Mitglied: C.R.S.
03.08.2020 um 20:04 Uhr
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.
Bitte warten ..
Mitglied: MysticFoxDE
04.08.2020 um 08:38 Uhr
Moin Thomas,

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
Bitte warten ..
Mitglied: MysticFoxDE
04.08.2020 um 09:02 Uhr
Moin C.R.S.,

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
Bitte warten ..
Mitglied: MysticFoxDE
04.08.2020 um 19:18 Uhr
Moin C.R.S.,

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
Bitte warten ..
Ähnliche Inhalte
Windows Server

Windows Server 2012 Netzwerkadapter deaktiviert

Frage von JoselieseWindows Server10 Kommentare

Ich brauche dringend fachmännischen Rat. Nach einem 3stündigen Telefonat bezüglich eines Problems mit den Remotenetzwerkdiensten hat es der Microsoft-Support ...

Windows 7

Windows 7 Tresor Anmeldespeicherung ist deaktiviert

gelöst Frage von TecFrekWindows 72 Kommentare

Servus Leute, ich habe ein kleines Problem mit Windows 7 Pro. Vor Kurzem hat sich mein Netzlaufwerk zu meinem ...

Netzwerkprotokolle

Delay auf TCP-Pakete unter Windows 7

gelöst Frage von luftikusNetzwerkprotokolle9 Kommentare

Hallo zusammen, ich möchte gerne einen Delay von 300 ms auf alle ausgehenden TCP-Pakete von einem bestimmten Port (und ...

Exchange Server

3 Firmen, 3 Windows-Domänen auf einem Exchange

Frage von wfc-itExchange Server4 Kommentare

Hallo Admins Ich habe da ein Thema bei dem ich gerade nicht weiter komme, und zwar: Ich habe einen ...

Neue Wissensbeiträge
Monitoring

Unabhängiger Ansatz - IoT (frei von Cloud- oder Appzwang) - Hier mit Schaltsteckdosen

Anleitung von beidermachtvongreyscull vor 1 TagMonitoring1 Kommentar

Tach Kollegen, ich erzähle Euch mal von meiner Ausgangslage und den/m Problem(chen) Ich benutze ein NAS zur Lagerung meiner ...

Microsoft
Microsoft Advanced Threat Protection for Linux
Information von Dani vor 3 TagenMicrosoft

Microsoft Defender Advanced Threat Protection (MD ATP) support for Linux with kernel version 3.10.0-327 or later, including the following ...

Humor (lol)
! ! Today ist SysAdmin-Day ! !
Information von VGem-e vor 5 TagenHumor (lol)5 Kommentare

Moin, "Happy Birthday" an alle Systemadministratoren, Mausschubser, System-/EDV-Betreuer, SysOps etc!! Siehe auch. Edit (Video hinzugefügt): Gruß VGem-e

Exchange Server
Basic Authentication and Exchange Online
Information von Dani vor 7 TagenExchange Server

Today we are pleased to announce some new changes to Modern Authentication controls in the Microsoft 365 Admin Center, ...

Heiß diskutierte Inhalte
Google Android
Handy gehackt ? - Gegemassnahmen
Frage von hushpuppiesGoogle Android26 Kommentare

Hallo zusammen, folgendes Szenario: Kollegin kommt heute zu mir und erzählt, dass ihre Tochter gestern über WhatsApp von einem ...

Google Android
Smartphone - Internes Radio auf Bluetooth Lautsprecher abspielen
Frage von emeriksGoogle Android25 Kommentare

Hi, vielleicht kann ja einer von Euch auch sowas beantworten. Ich habe hier ein Samsung Smartphone - S10 Lite. ...

Ausbildung
Wie wird man zum Systemadministrator?
gelöst Frage von DavidHergAusbildung24 Kommentare

Guten Abend zusammen, Ich hatte hier schon ein paar Fragen gestellt, und mir wurde super weiter geholfen! Ich mache ...

Windows Server
DCPromo bleibt bei Migration Server 2008R2 auf 2016 hängen
gelöst Frage von Leo-leWindows Server20 Kommentare

Hallo Forum, wir sind gerade dabei, unsere beiden DCs auf Server 2016 zu migrieren. Aktuell hängt der zusätzlich ins ...

Weniger Werbung?
Administrator Magazin
07 | 2020 In der Juli-Ausgabe beleuchtet das IT-Administrator Magazin den Themenschwerpunkt "Monitoring & Support". Darin zeigt die Redaktion unter anderem, wie Sie die Leistung von Terminalservern im Blick behalten und welche Neuerungen das Ticketsystem OTRS 8 mitbringt. Auch die Überwachung von USV-Anlagen darf nicht fehlen. In ...