Hallo Forum,
ich habe ein Delphi Tool geschrieben, dass über Modbus TCP Sockets mit
einem uController redet. Das Tool sendet die Anfragen und der
uController antwortet darauf.
Das Tool läuft auch, alles wunderbar.
Nun setzt der Kunde einen neuen Virenscanner ein (Kaspersky) und das
Tool wird dann nach dem Aufbau der Verbindung ziemlich träge.
Es hilft nur das Deinstallieren des Virenscanner, dann geht es wieder.
Deaktivieren oder das Tool als vertrauenswürdig einstufen hilft nicht.
Der Port 502 ist natürlich auch frei gegeben.
Gleiches habe ich mit einem anderen Virenscanner auch schon mal erlebt.
In Wireshark kann ich sehen, dass beim Kunden recht regelmäßig nur ca.
jede halbe Sekunde eine Anfrage vom Tool an den uController gesendet
wird, obwohl dies häufiger geschehen soll. Bei mir am Rechner sehe ich
teils bis zu 12 Anfragen pro Sekunde.
Die Antwort vom uController kommt dabei immer prompt, wenn auch bei mir
ein Ticken (Bruchteil einer Sekunde) schneller als beim Kunden.
Dabei ist es egal ob ein Register oder mehrere am Stück ausgelesen
werden.
Jedoch beim Kunden immer nur eine Anfrage ca. alle 0.5 Sekunde.
Irgendwas macht der Virenscanner, aber was?
Vermutlich die TCP Pakete überprüfen...
Hat jemand eine Idee, wie ich das Problem weiter eingrenzen kann bzw.
was es sein könnte?
Bisher hat keine Einstellung im Virenscanner etwas gebracht.
Vom Support kommt leider auch keine Hilfe und der Kunde möchte nicht
wechseln, bzw. gibt das Tool auch an seine Kunden weiter, wo dann das
gleiche Problem entstehen kann.
Gruß
Hugo
So mit Port 1050 bekomme ich erst gar keine Verbindung hin.
Mit Port 1028 geht es bei mir ganz normal, beim Kunden mit Kaspersky
genau das selbe Problem wie vorher auf Port 502.
Trotzdem Danke für die Idee!
Hugo schrieb:> Lohnt es noch andere Ports durchzuprobieren?
Nein, ich hatte nur angenommen das der Scanner eventuell spezielle
Protokolle filtert.
Letzendlich musst du dem Kunden klar machen, das hier deine
Zuständigkeit endet. Wenn er das Netzwerkabel durchschneidet wird es
noch langsamer... aber eine Lösung in Software ist dann trotzdem nicht
möglich ;-)
Hallo Hugo,
wir haben mit neueren Versionen unseres Virenscanners (nicht Kaspersky)
auch massive Probleme
(allerdings nicht mit solchen Programmen wie Du sie beschreibst, sondern
eher im Zusammenhang mit käuflichen Tools die sich tief ins System
einhängen)
1) dramatische Performance-Einbußen wenn der Virenscanner installiert
ist
2) aus Sicherheitsgründen lässt sich vieles nicht einfach so abschalten
(liegt zum Teil auch an den angewendeten Policies, kommt für den
Toolanwender aufs gleiche raus)
3) die Treiber verbleiben aktiv im System selbst wenn Funktionen
deaktiviert werden, das führt dazu dass Probleme bleiben obwohl die
Funktionen eigentlich deaktiviert werden-> nur deinstallieren hilft
Moderne Virenscanner versuchen über viele Mechanismen "ungewöhnliches"
Verhalten aufzudecken, die Mechanismen werden nicht genau erläutert ;-))
Wir haben zur Untersuchung:
a) den Testfall/Problemprogramm stark vereinfacht -> kannst Du nur Teile
Deines Programms verwenden und schauen ob Du da schon Probleme siehst ?(
ohne µC-Kram, nur das Senden der Anfragen reicht vielleicht)
b) mit Procmon geloggt -> riesige Datenmengen, muss eigentlich ein
Spezialist lesen, größtes Problem ist dass Procmon u.U. nicht die
Zusammenhänge sieht die er sehen müsste um das Problem zu sehen,
Stichwort "Allocated Altitudes"
Alles nur ein paar Gedanken, vielleicht hilft es in einem Fall ein wenig
?
Vielleicht aber viel zu weit weg von Deinem Thema...
Viel Erfolg! (bzw. Beileid)
Gruß,
Erik
Das klingt nicht sehr ermutigend... trotzdem danke für die Antworten!
Mein Programm macht ansonsten so gut wie nichts anderes, als Daten
abfragen, in Edit Felder eintragen und wenn auf dem uController ein
bestimmtes Programm abläuft ein live Logging und Zeichnen eines
Diagramms.
Das Logging und Zeichnen habe ich schon ohne Verbesserung rausgeworfen.
Die Probleme fangen schon nach dem reinen Verbinden an, wo dann nur
regelmäßig geringe Datenmengen abgefragt werden und einmalig am Anfang
mehrere Requests laufen um alle Daten zu holen.
Da die Daten verstreut aus einem bestehenden Datenpool geholt werden,
mache ich das nicht in einem Request, sondern in mehreren Requests, was
eigentlich keim Problem ist. Vielleicht nicht optimal, aber eher selten
und zu dem Zeitpunkt überhaupt nicht störend, da ansonsten nichts
kritisches läuft.
So wie der Log mit Wireshark aussah, würde ich aber die 800+ Daten mit
einem zusammenhängenden Request auch extrem schnell bekommen. Problem
sind also die einzelnen Anfragen und Antworten die am PC extrem
ausgebremst werden, egal wie viele Daten angefordert werden. Bzw. die
Anforderung vieler Daten ist ja auch nur ein Request mit einer großen
Zahl in einem Datenfeld, auf die Der Controller mit einer längeren
Antwort und ggf. mehreren Datenpaketen antwortet. Aber der uController
antwortet sofort. Das Auswerten auf Toolseite ist dann wieder langsam,
so dass RTT abläuft und ein ACK vom Tool gesendet wird.
Ich sollte mal testen, ob eine andere Modbusverbindung (z.B. zu einer
Wago) auch ausgebremst wird. Und zwar von meinem (abgewandelten) Tool
oder von einem anderen Tool mit anderm Modbus Stack.
Vielleicht bekomme ich so raus, ob den Virenscanner mein Tool an sich,
oder meine Datenpakete stören...
Dem Kunden zu sagen: dein Pech! ist natürlich nicht wirklich eine
Option, auch wenn das Problem nicht in meiner Hand liegt.
Eine genauere Problemanalyse gibt da bessere Argumente an die Hand und
hoffentlich einen Lösungsweg!
Notfalls muss ich das ganze Programm auf einen anderen Stack oder in
eine andere Programmiersprache portieren, das wäre natürlich schon
ziemlich blöd.
Gruß
Hugo
Hugo schrieb:> Notfalls muss ich das ganze Programm auf einen anderen Stack oder in> eine andere Programmiersprache portieren, das wäre natürlich schon> ziemlich blöd.
Das wird wenig helfen, denn das Problem (Kaspersky) bleibt.
wie wäre es einen µC damit zu beauftragen alle daten als master zu
sammeln und von diesem Master so oft an de PC zu senden wie es Kaperski
erlaubt
dann geht nichts verloren und es ensteht nur eine leichte verzögerung.
sprich PC ist nicht master sondern ein Slave
Namaste
Achja und falls du das externe Masterkonzept aufgreifst, dann schreibe
mir bitte.
Ich bin an einem ähnlichen Projekt bei dem eine SPS sich auch zickkig
hat zb. wenn ein Busteilnemer temporär aussteigt die Verbindung später
wieder aufzubauen.
Deshalb will ich einen µC dazwischen hängen welcher den Buss managed
und p2p mit der SPS verbunden wird
Hallo
Vielleicht nützt es mit den Einstellungen des Scanners zu spielen.
Deaktivieren ist sowieso keine Lösung. ;-)
Du hast ja schon das Programm als vertrauenswürdig Eingestuft.
Dann noch z.B. den Haken bei Programmaktivität nicht kontrolliern
und Netzwerkverkehr nicht untersuchen
Dann gibt es noch mehr solche Einstellungen aber das könnte eventuell
reichen oder aber es nützt alles nichts.
Viel Erfolg
Hallo,
nach einer Woche Urlaub geht es weiter...
In der Zwischenzeit hat der Kunde ein kleines C# Testprogramm als
Vergleich von mir bekommen, mal sehen wie sich Kaspersky da verhält.
Ich werde die Vorschläge zu den Kaspersky Einstellungen auch mal weiter
geben.
Selber habe ich die Einstellungen beim Kunden nicht vorgenommen, ich
hatte nur Kontakt zu deren IT. Aber angeblich haben sie alles
versucht...
Vielleicht sollte ich mir das vor Ort mal selber genauer ansehen oder
ein Kaspersky bei mir installieren...
TCP_NODELAY Flag habe ich vermutlich nicht gesetzt.
Meinst du den "Nagle algorithm"? Muss ich mir noch mal ansehen.
Ich werde berichten.
Danke!
Hugo
So wie ich das verstehen, ist das "TCP_NODELAY" eine Option des TCP/IP
Stacks des Betriebssystems und kann dort deaktiviert werden.
Ich habe ja noch einen TCP/IP Stack auf der Mikrocontrollerseite und im
Delphi Tool.
Bei mir macht es aber mit der Standardeinstellung (im Betriebssystem)
keine Probleme.
Wo ist da der Zusammenhang mit dem Virenscanner?
Also die Tool Alternative unter C# mit anderem Modbus und anderem TCP/IP
Stack hat -wie vermutet- auch nichts gebracht.
Das mit dem Nagle Algorithmus klingt interessant, aber ich verstehe den
Zusammenhang zum Virenscanner dabei nicht.
So wie ich es verstanden habe, ist das eine Einstellung des PC
Betriebssystems.
Es müsste doch dann auch ohne Virenscanner schon langsamer sein.
Oder verändert der Virenscanner evtl. diese Einstellung?
Kann ich das TCP_NODELAY auch im Datenpaket selber setzen?
Hugo schrieb:> Das mit dem Nagle Algorithmus klingt interessant, aber ich verstehe den> Zusammenhang zum Virenscanner dabei nicht.> So wie ich es verstanden habe, ist das eine Einstellung des PC> Betriebssystems.
Nein. Es ist ein binäres Flag des jeweiligen TCP Sockets und kann für
jeden Socket (für jeden TCP Endpunkt) getrennt gesetzt/gelöscht sein.
> Oder verändert der Virenscanner evtl. diese Einstellung?
Das ist möglich. Eventuell dient der Virenscanner als transparenter
Proxy, und der wird dann ganz selbstverständlich das Zeitverhalten
beeinflussen.
> Kann ich das TCP_NODELAY auch im Datenpaket selber setzen?
Das ist eine Einstellung des TCP Endpunktes an sich und kein Bestandteil
eines Datenpaketes.
fchk
Winfried J. schrieb:> wie wäre es einen µC damit zu beauftragen alle daten als master zu> sammeln und von diesem Master so oft an de PC zu senden wie es Kaperski> erlaubt> dann geht nichts verloren und es ensteht nur eine leichte verzögerung.
Ich weiß nicht, ob das was bringt. Ziel ist ja quasi ein Livelogging.
Außerdem erfordert es zusätzliche HW und SW.
Es muss eine andere Lösung geben!
Frank K. schrieb:> Das ist eine Einstellung des TCP Endpunktes an sich und kein Bestandteil> eines Datenpaketes.
Ok danke.
Aber die Socketeinstellung bzw. Erzeugung ist bei mir und beim Kunden ja
genau gleich.
Es läuft die gleiche FW auf dem Mikrocontroller und das Tool ist auch
das gleiche...
Ich kann es natürlich ausprobieren.
Auf welcher Seite müsste ich es denn dann einstellen?
Das PC Tool fragt den Mikrocontroller ab.
Also vermutlich auf der Mikrocontrollerseite, richtig?
Mein TCP/IP Stack auf dem Controller scheint das nicht zu
unterstützen...
Aber es erscheint mir auch unsinnig.
Es werden mit dem Algorithmus ja Daten gesammelt und in ein Paket
zusammen gefasst.
Ich sehe aber im Wireshark quasi sofort eine Antwort des Controllers.
Nur die Auswertung (bis die Daten von der Schnittstelle im Tool sind)
dauert dann recht lange, so dass im Tool auch keine Rückmeldung in der
Titelzeile steht.
Also kann es meines Verständnisses nach der Algorithmus nicht das
Problem sein.
Der Virenscanner verzögert die Weitergabe der Daten von der
Schnittstelle zum Tool!
Außerdem sagt spricht die Nagle Algorithmus Beschreibung von single Byte
Paketen. Bei mir ist die Datenmenge anscheinend egal.
Es kann ein Word oder mehrere Words enthalten sein. Immer die (gleiche)
Verzögerung.
Man sollte sich auch ueberlegen, ob man auf einem Prozessrechner einen
Virenscanner braucht, ob man auf einem Prozessrechner das Internet
braucht. Gibt es denn etwas zu surfen ? Will man sich von der Mosad
einen Virus aufspielen lassen ?
Hugo schrieb:> Naja, da vom PC aus nicht gesteuert wird, sondern nur mitgeloggt werden> soll, kann ich schon verstehen, wenn das nur nebenher laufen soll.
Wenn nur live mitgeloggt und nicht gesteuert werden soll, so wäre das
auf einem interruptfähigen "Echtzeitsystem" sinnvoll, wohhingegen die
Darstellung öfter als mit Bildwiderholfrequenz unsinnig erscheint. Ein
separater µC könnte beide Probleme lösen, eventuel sinnvoller als im
Kaperski eine unerwüschte Backdoor zu installieren.
Aber jeder nach seinem Geschmack.
Hugo schrieb:> Außerdem sagt spricht die Nagle Algorithmus Beschreibung von single Byte> Paketen. Bei mir ist die Datenmenge anscheinend egal.> Es kann ein Word oder mehrere Words enthalten sein. Immer die (gleiche)> Verzögerung.
Hast Du es auch mit großen Datenpaketen probiert, die größer als ein
Ethernet-Paket sind? Das ist nämlich das Ziel - Zusammenfassung mehrerer
kleiner Pakete zu einem großen, um die zur Verfügung stehende Bandbreite
besser auszulasten.
Stacks für kleine Mikrocontroller haben diesen Algorithmus aus
Speicherplatzmangel oft nicht implementiert.
fchk
Ich glaube nicht, dass es daran liegt, da ich auf meine Anfrage vom PC
Tool quasi sofort eine Ack und eine zweite Nachricht mit den
angeforderten Daten vom Mikrocontroller bekomme. Das klappt ja immer und
hier hätte ich dann jetzt das Problem mit kleinen Datenpaketen erwartet.
Das Problem ist aber dann auf PC Seite, dass das PC Tool anzeigt "Keine
Rückmeldung" und die Daten lange "bis ins Programm" brauchen.
Nagle würde ja vor dem Lossenden auf mehr Daten warten und sammeln.
Meine Daten gehen aber quasi sofort raus.
Es ist eindeutig eine Verlangsamung beim Empfang auf PC Seite.
Also so, als wenn "jemand" sich die Daten genauer anschaut, bevor es
weiter geht... also der Virenscanner. Weil ohne ihn funktioniert es ja.
Ich hänge mal zwei Bilder aus zwei Wireshark Logs zur Verdeutlichung an.
In der zweiten Spalte von links sieht man den Timestamp.
Schwarz hinterlegt ist die Anfrage vom PC Tool. Dann kommt ein Ack vom
Controller und ein zweites Paket mit den gewünschten Daten.
Ohne Virenscanner geht es sofort mit der nächsten Anfrage weiter.
Mit Virenscanner läuft die RTT ab und es wird ein erzwungenes Ack vom PC
Tool gesendet. Dann dauert es noch ein bisschen und dann kommt erst die
nächste Anfrage vom PC an den Controller. Also zwischen den Anfragen
liegen ca. 0,5s mit Virenscanner. Ohne Virenscanner sind es ca. 0,03 bis
0,04s!!
Also das Delay ist eindeutig auf der Empfangsseite des PCs.
Noch als Hinweis:
Nicht wundern, dass dort etwas von falschen TCP Checksummen steht.
Das liegt daran, dass Wireshark bei bestimmten Windows Einstellungen die
Pakete abgreift, bevor die richtige Checksumme berechnet wurde.
Zur CPU Entlastung wird die Checksummenberechnung auf die Netzwerkkarte
ausgelagert, Wireshark zapft aber vorher schon die Pakete an.
H. Schmidt schrieb:> PUSH-Flag gesetzt ?
In den Nachrichten vom PC Tool an den Controller ist das PUSH Flag
gesetzt.
In den Antworten vom Controller an den PC nicht.
Ich weiß aber gerade auch nicht, wie ich das setzen kann und ob es
überhaupt vom verwendeten TCP/IP Stack unterstützt wird.
H. Schmidt schrieb:> PUSH-Flag gesetzt ?
Das Setzen des PUSH Flags hat geholfen!
Ich setze es jetzt in allen Nachrichten vom Controller an den PC, also
sowohl in den reinen ACK Nachrichten, als auch in den Nachrichten mit
Daten und es scheint beim Kunden zu laufen!
Vielen vielen Dank für den Tipp!
