rocktale
Ich fühle mich ja zugegeben bei "Blödsinn" nicht angesprochen, aber wenn wir schon Haare spalten wollen, dann machen wir es richtig.
Aber: Wir reden hier von einem 10GbE-Ethernet, in dem in der Regel nicht so viele Pakete verloren gehen. Dazu kommt, dass TCP bei bestehenden Verbindungen nach dem Slow Start recht schnell das Fenster der zu sendenden Pakete bis es auf ein ACK wartet vergrößert. Genau aus dem Grund funktioniert ja auch die Übertragung großer Dateien in der Regel mit (konstant) hoher Datenrate - auch über TCP.
Ein weiterer Grund könnte natürlich der zusätzliche Aufbau einer Verbindung sein (3-Wege-Handshake von TCP). Auch wenn ich auf die Schnelle nichts gefunden habe, gehe ich aber mal stark davon aus, dass sowohl halbwegs aktuelle Versionen von SMB als auch NFS eine TCP-Verbindung offen halten. Der Handshake fällt dann also auch nur einmal an (beim Einbinden vom Laufwerk) und nicht bei jeder Datei neu. Scheinbar ist NFS da sogar so effizient, dass sie in der Version 4 ja meines Wissens sogar den Support von UDP gestrichen haben.
Das Problem liegt nach meiner Erfahrung darin, dass die ganzen Anwenderprogramme, von denen wir hier reden, auf Standard-Dateioperationen vom OS setzen. Sprich: Da wird eine Datei geöffnet, daraus gelesen, Datei geschlossen und dann die nächste. Sind das nur OS-Calls geht das rasend schnell. Wenn aber jede dieser Schleifen übers Netz muss, dann heißt das im absoluten Minimum: ein Paket mit Anfrage welche Datei gelesen werden soll hin + ein oder mehrere Pakete mit Daten vom Server zurück. Und das kann man auch nicht parallelisieren, weil die Programme dafür nicht ausgelegt sind. Da werden die Dateien einfach nacheinander geladen. Und bei jedem dieser Calls wartet man zusätzlich zu allem Overhead eben auf (mindestens) einen Roundtrip im Netz. Und selbst wenn das relativ zügig geht - ich hab hier Pings zwischen 0.3 und 0.5ms, aber da werden ja noch keine Infos verarbeitet - summiert sich das über die einzelnen Dateien auf. Also sagen wir mal mit Dateizugriff beim Server ganz grob 1ms pro Datei... dann sind das bei 20.000 Samples eben auch schon 2s.
Die einzige Lösung wäre hier prädiktives Laden von mehr Daten und/oder Caching beim Client. Oder eine effizientere Implementierung des Datenzugriffs seitens der Plugins/Audiosoftware. Letzteres halte ich aber bis auf weiteres für unwahrscheinlich.
Ich würde anzweifeln, dass UDP hier so viel hilft, um ehrlich zu sein. UDP ist vor allem bei Echtzeit von Bedeutung, wenn man auf die Fehlerkorrektur durch wiederholtes Senden eines verlorenen Paketes verzichten kann, was sonst - bei einer schlechten Netzverbindung - ganz schnell einen Datenstrom zum Erliegen bringt. Die Vorteile kann es aber vor allem beim Streaming - also bei einem kontinuierlichen Datenstrom mit wenig bis keinem Kontrollfluss ausspielen. Deshalb wird es auch gern als Basis für Videostreaming eingesetzt, da man hier notfalls auf ein paar Informationen verzichten kann (kleine Artefakte im Bild)... ein stockendes Bild aber extrem lästig ist.Viele kleine Dateien sind immer eine Herausforderung, egal ob übers Netz oder lokal. Wie oben schon geschrieben, übers Netz kann man das Problem minimieren indem man auf UDP geht.
Aber: Wir reden hier von einem 10GbE-Ethernet, in dem in der Regel nicht so viele Pakete verloren gehen. Dazu kommt, dass TCP bei bestehenden Verbindungen nach dem Slow Start recht schnell das Fenster der zu sendenden Pakete bis es auf ein ACK wartet vergrößert. Genau aus dem Grund funktioniert ja auch die Übertragung großer Dateien in der Regel mit (konstant) hoher Datenrate - auch über TCP.
Ein weiterer Grund könnte natürlich der zusätzliche Aufbau einer Verbindung sein (3-Wege-Handshake von TCP). Auch wenn ich auf die Schnelle nichts gefunden habe, gehe ich aber mal stark davon aus, dass sowohl halbwegs aktuelle Versionen von SMB als auch NFS eine TCP-Verbindung offen halten. Der Handshake fällt dann also auch nur einmal an (beim Einbinden vom Laufwerk) und nicht bei jeder Datei neu. Scheinbar ist NFS da sogar so effizient, dass sie in der Version 4 ja meines Wissens sogar den Support von UDP gestrichen haben.
Das Problem liegt nach meiner Erfahrung darin, dass die ganzen Anwenderprogramme, von denen wir hier reden, auf Standard-Dateioperationen vom OS setzen. Sprich: Da wird eine Datei geöffnet, daraus gelesen, Datei geschlossen und dann die nächste. Sind das nur OS-Calls geht das rasend schnell. Wenn aber jede dieser Schleifen übers Netz muss, dann heißt das im absoluten Minimum: ein Paket mit Anfrage welche Datei gelesen werden soll hin + ein oder mehrere Pakete mit Daten vom Server zurück. Und das kann man auch nicht parallelisieren, weil die Programme dafür nicht ausgelegt sind. Da werden die Dateien einfach nacheinander geladen. Und bei jedem dieser Calls wartet man zusätzlich zu allem Overhead eben auf (mindestens) einen Roundtrip im Netz. Und selbst wenn das relativ zügig geht - ich hab hier Pings zwischen 0.3 und 0.5ms, aber da werden ja noch keine Infos verarbeitet - summiert sich das über die einzelnen Dateien auf. Also sagen wir mal mit Dateizugriff beim Server ganz grob 1ms pro Datei... dann sind das bei 20.000 Samples eben auch schon 2s.
Die einzige Lösung wäre hier prädiktives Laden von mehr Daten und/oder Caching beim Client. Oder eine effizientere Implementierung des Datenzugriffs seitens der Plugins/Audiosoftware. Letzteres halte ich aber bis auf weiteres für unwahrscheinlich.