Aussetzer im TCP-Transfer alle 10min

Heimnetzwerke - WIFI, LAN, Router und Co 16.538 Themen, 81.400 Beiträge

Aussetzer im TCP-Transfer alle 10min

michasabg am 08.02.2008, 15:54 / 4 Antworten / Baumansicht

Hallo Leute,
wir übertragen per TCP/IP Video-Daten, was einen möglichst kontinuierlichen Datenstrom erfordert, denn auch Puffergrößen beim Empfänger sind endlich. Es handelt sich um ein vollkommen autarkes Netzwerk, ein PC und n Empängermodule. Seitdem wir alle Broadcast-Quellen in Windows angeschaltet haben (Freigabedienste, Netbios etc.) funktioniert das soweit stabil. Nur exakt alle 10 min gibt es einen Aussetzer im Transfer für ca 1-2s, was im ungünstigsten Fall zu einem Buffer-Underrun beim Empfänger führt. Ich habe gelesen, dass unter Windows alle 10min der Arp-Cache gelöscht wird, was uns aber als Ursache wenig wahrscheinlich erscheint. Kennt jemand in der Runde noch andere Operationen, die das Betriebssytem in diesem Rhythmus auf Netzwerkverbindungen ausführt? Übrigens tritt der Effekt auch auf einem Mac auf.

supaburn1

michasabg „Aussetzer im TCP-Transfer alle 10min“

11.02.2008, 20:15 Optionen

Hallo,

also ich kann mich wage daran errinern das NETBIOS/NETBEUI ca. alle 10 min einen broadcast schickt bzw. eine anfrage ob neue Clienten dazugekommen sind.

mehr kann ich dir leider auch gerade nicht helfen

mfg

michasabg

supaburn1 „Hallo, also ich kann mich wage daran errinern das NETBIOS/NETBEUI ca. alle 10...“

11.02.2008, 22:00 Optionen

Hallo supaburn1,

danke für den Hinweis. Ich habe gerade bemerkt, dass mir in meinem Text ein Fehler unterlaufen ist. Wir haben natürlich Netbios, Freigabedienste etc. abgeschaltet, da sonst wirklich störende Broadscasts durchs Netz fliegen. Das kann bei Windows-Netzwerken ziemlich heftig werden. Als Transportprotokoll verwenden wir ausschließlich TCP/IP, NETBUI ist nicht installiert. Da sonst niemand eine Idee hatte, werden wir erst mal die Arp-Cache Geschichte verfolgen und schaun, ob das Verwenden statischer Arp-Einträge bzw. das Ändern des Timings für den Refresh in der Registry etwas bringt. Ich werde das Ergebnis hier posten.

Gruß
michasabg

supaburn1

michasabg „Hallo supaburn1, danke für den Hinweis. Ich habe gerade bemerkt, dass mir in...“

12.02.2008, 23:24 Optionen

hmm ja okay ich würde den selben weg wie du (ihr) gehen...

vielleicht mal wireshark oder anderen netzwerk sniffer installieren und schauen was passiert?

bitte nicht vergessen das ergebnis zu posten würd mich auch mal interessieren was da los man lernt ja nie aus...

viel glück und mfg

michasabg

supaburn1 „hmm ja okay ich würde den selben weg wie du ihr gehen... vielleicht mal...“

06.03.2008, 22:52 Optionen

Hallo supaburn1,

hat ein bisschen gedauert, hatte viel um die Ohren und wollte das auch an verschiedenen Standorten testen, damit das Ergebnis gesichert ist.
Es ist also tatsächlich so, dass das Problem durch den Refresh des Arp-Cache verursacht wird. Da das Paket-Routing letztendlich über die MAC-Adresse eines Netzwerkadapters läuft, ist Windows bzgl. dyn. MAC-Einträge während des Refreshs blind, die Kommunikation ist blockiert.

Zum Glück sind statische Einträge von dem Effekt nicht beroffen, sodass man ihn umgehen kann. Mit dem Kommando arp -s kann man selbst statische Einträge im Arp-Cache platzieren, was für bekannte Gegenstellen kein Problem ist. Deren MAC-Adresse bekommt man einfach heraus, man muss diese nur mit dem Kommando ping + IP-Adresse ansprechen und danach im eigenen Arp-Cache mit dem Kommando arp -a den dyn. Eintrag auslesen.

Einen kleinen Wermustropfen hat das Verfahren. Die IP-Adresse der Gegenstelle(n) muss natürlich statisch sein und der Arp-Cache wird beim Start des Betriebssystems neu gefüllt, auch statische Einträge gehen beim Herunterfahren verloren. Also bleibt nur der Weg, die Initialsierung per Batch-Job beim Hochfahren zu erledigen. Da das aber ein einmaliger Einrichtvorgang ist, stellt das eine praktikable Lösung dar.

Der Zyklus von 10 min hängt wie zu erwarten an einem Registry-Eintrag (ArpCacheMinReferencedLife unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters), der aber hidden ist und von Windows per default auf 600 Sekunden initialisiert wird. Das heißt, dass man den selbst erst anlegen muss, wenn man ihn auf einen anderen Wert setzen will. Für Änderungen an der Registry gilt natürlich der alte Grundsatz: Erst sichern, dann schrauben !!!

Das Thema ist sicher recht speziell, aber falls doch mal jemand einen kontinuierlichen Datenstrom per TCP/IP realsieiren muss, bleibt als Fazit: alle Freigabedienste, NETBIOS und dyn. Arp-Cache abschalten bzw. durch statische Einträge umgehen. Damit funktioniert das jetzt zumindest bei uns ohne Probleme.

Gruß, michasabg