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
Hugo schrieb: > Der Port 502 ist natürlich auch frei gegeben Probier es doch mal mit einem Port > 1024, eventuell ist der Virenscanner da gnädiger.
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!
Ich hatte mich bei den Portnummern an der Tabelle auf Wikipedia orientiert und Lücken genommen. http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers Lohnt es noch andere Ports durchzuprobieren?
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 ;-)
:
Bearbeitet durch User
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
Bringt der Kaspersky evtl. eine eigene Firewall mit in der man Dein Programm freischalten könnte? Grüße Markus
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
Hugo schrieb: > TCP Sockets mit > einem uController Hast Du auch das TCP_NODELAY Flag gesetzt? Dein Problem klingt nämlich verdächtig nach Naegle.
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?
Kann jemand vielleicht etwas aus einem Wireshark Log herauslesen?
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 ?
Naja, da vom PC aus nicht gesteuert wird, sondern nur mitgeloggt werden soll, kann ich schon verstehen, wenn das nur nebenher laufen soll.
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
Angehängte Dateien:
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.