# .net Libnodave unter VM-Ware schneller als unter native Win7



## Zipfelklatscher (1 Juni 2012)

Hallo zusammen,

ich hab ein Programm unter VB.net Framework 4.0 geschmiedet welches Daten (200 Byte per TCP/IP) zyklisch mit Libnodave
aus der SPS (416-2DP) zieht und anschießend ein Statusword in die SPS schreibt um den Empfang
zu quittieren. Das läuft soweit ohne Probleme.

Aber wenn ich die Zeit für einmal lesen und Statuswort schreiben messe
dann erreiche ich bei einem nativ installierten Win7 32Bit SP1 *200* ms
und bei einem Win7 unter einer VM-Ware *9 ms *.

Kann sich vielleicht jemand vorstellen wieso ??

Danke


----------



## Fritz1001 (1 Juni 2012)

Win7 VM Ware ist win7 64bit mit gast XP32bit?


----------



## Zipfelklatscher (1 Juni 2012)

Nein ist MacOS X mit Parallels Desktop und Win7 SP1 32Bit . Hier benötigt das Programm nur 9ms
Wenn ich das Programm unter nativ Win7 SP1 32Bit kompiliere und es teste werden 200 ms benötigt.


----------



## LowLevelMahn (2 Juni 2012)

*Wie wird denn deine Zeit gemessen?*

Wie sieht denn dein Benchmark aus?

Es gibt ja x Wege die Zeit zu Messen - mit Latenz zwischen 2-5 uSec und 20-30 mSec ...

Wie viele Leseoperationen mit Zeit-Durchschnitt machst du denn? unter 100 (besser 1000) mal würde ich keiner Zeit-Messung glauben schenken

mehr Details?


----------



## Magik_Niq (5 Juni 2012)

Oft ist ein VM nicht anstrengend belastet => in diesen Fall nur das TCP/IP Programm, sonst hat win7 immer mehrere Programmen laufende wer in diesen Zeit auch CPU-zeit brauchen. Wenn VM z.B. 40% CPU Zeit bekommt ist das genugend für 5ms, aber wenn Win7 gleichzeitig auch Treibers, Word, Chrome, TwinCAT, VM lauft dan sind 5ms vielleicht nicht genugend für diese Programm Zeitraum zu geben. So wird diese Paradox gelöst.


----------



## LowLevelMahn (5 Juni 2012)

*bisschen einfach oder?*

@Magik_Niq

Ohne klar zu wissen was er wirklich macht ist das schon sehr spekulativ - oder? 
Klar kann die VM den zugeteilten CPU happen voll nutzen - aber sie muss trotzdem wieder durch dass Host Bestriebssystem durch
vielleicht laufen auf seinem Win7-System noch andere TCP/IP Blockierer - 9ms zu 200ms ist schon ein sehr grosser Sprung (20 mal so schnell?) den man
glaube nicht mit Scheduling erklären kann

Oder seine Zeitmessung ist einfach schlecht


----------



## Magik_Niq (5 Juni 2012)

LowLevelMahn schrieb:


> @Magik_Niq
> 
> Ohne klar zu wissen was er wirklich macht ist das schon sehr spekulativ - oder?
> Klar kann die VM den zugeteilten CPU happen voll nutzen - aber sie muss trotzdem wieder durch dass Host Bestriebssystem durch
> ...


Ganz abhängig von welche VM, wie es konfiguriert ist und welche Priorität TCP/IP stack hat auf Win7 host. Mit hohe Prio TCP/IP aber kein Prio für .net Programm erklärt es sich so einfach. Aber ich gebe nur eine Möglichkeit in Fall die Zeitmessung richtig ist da:



> Oder seine Zeitmessung ist einfach schlecht



Du die andere Möglichkeit bereits gegeben hattest. Zwei Sachen zum überprüfen:
- Zeitmessung,
- Wie seht die Host Win7 aus.


----------



## Jochen Kühner (5 Juni 2012)

*Testprogramm*

Hab mal ein kleines Programm angehängt, mit dem hab Ich als schon die Geschwindigkeit verglichen...


----------



## Zipfelklatscher (6 Juni 2012)

Bei der Zeitmessung gehe ich folgendermaßen vor.

Sobald begonnen wird die Daten auszulesen speichere ich mir die aktuelle
Zeit der CPU weg.
Sind alle Daten gelesen nehme ich wieder die aktuelle CPU Zeit und ziehe den
den vorher gespeicherten Wert davon ab. 

Dieses Verfahren müsste eigentlich passen.


----------



## LowLevelMahn (6 Juni 2012)

*komischer Benchmark*



> Sobald begonnen wird die Daten auszulesen speichere ich mir die aktuelle
> Zeit der CPU weg.



Wie genau ist denn die Zeiterfassung der CPU (Ist das nicht auch abhängig von der Zykluszeit)? Es macht aber definitiv keinen Sinn deine SPS als Zeitgeber zu benutzen

1. der Benchmark muss komplett auf dem PC laufen sonst wird ja die Latenz der Hin/Her Kommunikation mit eingebaut
unter VB.Net kannst du dafür die StopWatch verwenden (http://www.activevb.de/tipps/vbnettipps/tipp0082.html) 
-> alle anderen Zeitmessungs-Varianten sind einfach zu ungenau (teilweise 20-30ms daneben - also schon weit über deinen 9ms)

2. da es Schwankungen durch SPS,TCP/IP usw. gibt brauchst du eine Schleife die mind. 100 besser 1000 mal deine Abfrage durchspielt (und dann den Durchschnitt ermittelt)
-> alles andere ist total wertfrei (unabhängig von jedermanns Meinung)

Jochens ReadSpeedtest begeht leider (soweit richtig gesehen) auch die Benchmark-Todsünde des fehlenden Loops aus Punkt 2 

Wenn du die Teilkonfiguration(welche SPS, DBs/Variablen) mal mitteilst (als PN) würde ich einen AGLink-Benchmark bauen - als Vergleich - würde mich echt interessieren was du da für ein Probleme hast

Wenn du die Punkte 1-2 nicht so machst kannst du es dir sparen irgendwelche Benchmarks zu posten - die sind dann sowiso relativ sinnlos oder falsch - leider :|


----------



## Rainer Hönle (6 Juni 2012)

Und wenn dabei nur ein einzelner Durchlauf gemessen wird, dann gibt es viele Unsicherheiten: Granularität der Zeitmessung beim Start und Ende, Störeinflüsse durch Festplatte, ....
Wie Lowlevelman schon schrieb, für eine brauchbare Aussage muss der Test am Stück 100-1000 mal wiederholt werden, damit man mit den Vergleichswerten etwas anfangen kann.


----------



## Thomas_v2.1 (6 Juni 2012)

In den libnodave Testprogrammen ist doch ein Benchmark integriert, braucht nur mit der entsprechenden Option aufgerufen werden. Und die sind von Zottel schon ordentlich programmiert worden.
Die nutzen zwar nicht die .net Schnittstelle, aber ich denke nicht dass wenn das Programm einmal gestartet wurde zwischen .net und der nativen Schnittstelle ein großer Geschwindigkeitsunterschied besteht.


----------



## Zipfelklatscher (6 Juni 2012)

Sorry ich habe mich vorher ungenau ausgedrückt
die Messung findet natürlich auf der PC Seite statt
nicht auf der SPS Seite. Es wird die Zeit der PC CPU genommen.
Zum Starten und Stoppen
benutze ich auch die .net Funktion StopWatch .

Bei meinen letzten Tests unter nativ Win7 habe ich den Durchlauf ca. 50 mal
wiederholt und ich kam mit der Zeit nie wirklich runter. Blieb im Schnitt bei
*220*ms (Schwankung +-25 ms)

Im Gegenzug ab ich den Test auf der VM-Ware auch gemacht
und hier ging die Zeit nie hoch sondern blieb konstant 9ms (+- 2ms).


Das Libnodave Testprogramm werde ich noch testen.


----------



## LowLevelMahn (6 Juni 2012)

*Mehr Details*

220ms zu 9ms ist echt krass  - viel zu krass

ein paar Fragen:

1. Was sind denn jetzt deine Testsysteme? 
nativ Win7 32Bit?, MacOS X mit Parallels Desktop und Win7 SP1 32Bit, dann sprichst du plötzlich von VM-Ware? Was denn jetzt genau

2. Wie "sauber" sind deine Testsysteme - ist nativ komplett vermüllt also Step7,Twincat,8 Versionen von Wireshark,etc... und die VM ist jungfräulich frisch?
hast du andere nativen Systeme getestet? Mach den Test im Abgesicherten Modus mit Netzwerk - dann sind fast alle Services,Virenscanner und Firewalls ausgeschaltet

3. Was machst du genau in deinem Ablauf: "Einmal lesen und Statuswort schreiben" ist dein Testszenario, wie sind die 200Bytes im Lesen aufgebaut? 200 Byte-Variablen, 1600 Bits - was genau (ganz ganz genau)?
Ich würde wirklich gerne exakt deinen Ablauf nachbauen (damit du ihn bei dir direkt einfach laufen lassen kannst)


----------



## Zipfelklatscher (25 September 2012)

Hi,

Problem gelöst !!!

nein es war nicht das scheduling des hosts sondern der Virenscanner.  

Der Norten hat trotz freigegebenem Port die Geschwindigkeit beeinträchtigt.


Danke für Eure Hilfe.


----------

