TCP Read geht unter WinXP, gibt jedoch unter XP x64 time out

Guten Tag,

ich habe einen Server und Client programmiert, die über TCP kommunizieren.
Der Client verbindet auf den Server und dieser schickt dann Daten, die vorher durch flatten to string gehen und auf clientseite wieder zu dem bekannten Datenformat rückkonvertiert werden.
Der Server sendet dabei 4 Byte I32 die Größe der Datenstruktur mit TCP send und danach die Datenstruktur selbst auch per TCP send. (Cluster aus 2D I16 Arrays).
Der Client empfängt per TCP Read die 4 Byte, die die Größe beinhalten und empfängt danach mit einem zweiten TCP Read diese Anzahl Bytes.

Das funktioniert bisher auch ausgesprochen zuverlässig, wenn Client und Server auf LV 7.1 unter Win XP laufen.

Nun habe ich auf dem Client auf Win XP x64 gewechselt, wodurch folgendes Problem entstanden ist:
Das zweite TCP Read auf dem Client bricht mit einem Time Out und nur partiell empfangenener Datenmenge ab. Der timeout kommt auch, wenn ich das Limit auf z.B. 60000ms vergrößere.
Da die partielle Datenmenge nach Timeout stark schwankt von ca. 5 bis 9 MB, nehme ich nicht an, dass das Netzwerk zu langsam ist, sondern dass der Transfer irgendwo mittendrin stehen bleibt.
Der TCP Read Modus ist Standard.

Die gesamte Datenstruktur selbst ist typisch zwischen 20 und 30 MB groß und das Netzwerk eine Gbit Schnittstelle, die Server und Client direkt verbindet. Die Transferzeit sollte also im Bereich 300ms liegen.

Da es mit 32 Bit WinXP zuverlaessig geht, vermute ich, dass es an irgendeinem anderen Netzwerkverhalten von XP x64 im Vergleich zu XP 32 Bit liegt, was das Problem mit dem Abbruch bei TCP Read verursacht.
Zur Zeit behelfe ich mich etwas notgedrungen damit, dass ich den Client mit LV 7.1 in einer virtuellen Maschine unter XP 32 Bit laufen lasse.

Hat jemand eine Idee, was da zwischen LV 7.1 und XP x64 bei Netzwerksachen anders abläuft, ggf. vielleicht sogar einen Tipp, was ich bei XP x64 ändern muss, damit sich LV 7.1 darunter wie unter XP 32 Bit verhält?

Anzeige

Ich vermute, dass das auch an der alten LabVIEW-Version liegen könnte. Hast Du die Mögllichkeit das mal mit einer neuen (offiziell für 64Bit supporteten) Version zu testen?

Gruß Markus

Sorry für die späte Antwort. Ich konnte das Problem identifizieren. Ich habe auf dem WinXP x64 VirtualBox und das NAT des VirtualBox Netzwerktreibers läuft über die gleiche physische Netzwerkschnittstelle, worüber auch der Datentransfer vom Labview Client aus XP x64 läuft. Nehme ich den Treiber von VBox bei der Netzwerkschnittstelle unter XP x64 heraus, ist die Performance dort genauso gut, wie in der virtuellen Maschine mit XP 32 Bit, die virtuell auf der gleichen physischen Schnittstelle läuft. Wieso der VBox Treiber da die Netzwerkbandbreite auf dem Hostsystem beeinträchtigt (auch wenn gar keine virtuelle Maschine läuft) weiss ich nicht.

Weiterhin habe ich das identische Programm mit LV 2010SP1 auf Client und Server Seite ausprobiert und der Performancesprung ist etwa Faktor 5, jedoch nur, wenn ich die CPU Core Affinität auf 4 (Client) bzw. 6 Cores (Server) reduziere. Bei Freigabe aller Cores ist der Performancesprung nur ca. Faktor 3.
Eine Sache zu der ich gar nichts gefunden habe: Wie kann ich Labview beibringen, dass er nur im Bereich der NUMA Node Speicher allokiert, die auch zu dem Speichercontroller der CPU des jeweiligen Threads gehört?

Weiterhin bin ich mir nicht sicher, wann SubVI Inlining richtig was bringt (Übergabe größer Arrays?!? )?