4. Lange Funktionszeiten

Lange Funktionszeiten

  • N

    Hallo zusammen.
    Ich habe ein sehr spezielles Problem.
    Ich arbeite mit einer DLL die von einer Fremdsteuerung über TCP/IP diverse Daten auslesen kann. Wenn alles gut geht, dauert es ca. 17 ms ein Datum dieser Steuerung auszulesen. Wenn die Steuerung jedoch einmal in Störung stand, dauert es bei mir 400 ms ein einzelnes Datum auszulesen, was natürlich zu lang ist. Wenn ich es nicht besser wüsste, würde ich sagen, dass das ein Problem in der DLL ist. Jedoch funktinoiert das schnelle Auslesen dieser Daten beim Entwickler auch wenn eine Störung angestanden hat.
    Ich vermute, dass ich etwas bei der Programmierung der COM-Objekte oder bei der Einbindung der ATL falsch mache. Das Instanzieren des auszulesenden Objekte hab ich mit dem Entwickler der DLL zusammen gemacht. Das sollte in Ordnung sein.
    Ich liste mal auf was ich für das Einbinden der ATL tue:
    Dies wird ganz oben in der stdafx.h gemacht:
    #define _ATL_APARTMENT_THREADED
    #ifndef _SECURE_ATL
    #define _SECURE_ATL 1
    #endif
    #define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS

    #include <atlbase.h>
    #include <atlcom.h>
    #include <atlctl.h>
    #import "C:\Programme\Gemeinsame Dateien\Shared\Steuerungdnc.dll" raw_interfaces_only, raw_native_types, named_guids, auto_search, auto_rename

    Das instanzieren eines solchen echten Objektes wird dann folgendermaßen durchgeführt:
    Deklaration innerhalb der Klasse
    CComPtr<IMachine> m_pMachine;
    CComPtr<IDataAccess> m_pDataAccess;

    Der ausfuführende Code
    hr = CoInitialize(NULL);
    hr = m_pMachine.CoCreateInstance(CLSID_Machine);
    IUnknown pDataAccessObject;
    hr = m_pMachine->GetInterface(DNC_INTERFACE_DATAACCESS, &pDataAccessObject);
    hr= pDataAccessObject->QueryInterface(IID_IDataAccess,(void    😉 &m_pDataAccess);

    Von diesem m_pDataAccess kommen dann weitere COMPointer bis hin zur letzten instanz, die einem dann das Tatsächliche Nutzdatum zur Verfügung stellt.
    Dieser werden dann nich mit queryinterface instanziert, sondern sind Rückgabewerte aus m_pDataAccess und weiteren Hilfsobjekten.

    Hat jemand eine Idee was ich falsch mache?

    0

  • die von einer Fremdsteuerung über TCP/IP diverse Daten auslesen kann

    Kann es sein dass hier Nagle's Algorithm in Kombination mit Delayed-ACK zuschlägt?
    Ist häufig der Grund wenn irgendwas was mit TCP/IP zu tun hat auf einmal lange dauert.
    400ms is komisch, bei Windows ist das "übliche" Delay was entsteht immer ~1 Sekunde. Wenn auf dem Target allerdings kein Windows läuft, könnte es natürlich trotzdem daran liegen - das Delayed-ACK Timeout könnte ja genau so gut 400ms sein.

    0
  • N

    Das weiss ich nicht 🙂 Wie kann ich das denn überprüfen? Die TCP/IP verbindung übernimmt vollständig die DLL.
    Ich mein auf dem fremden System läuft irgendein Windows mit einem von der Firma selbst entwickeltem Realtime Operating System

    0

  • Delayed-ACK kannst du am Client schonmal über die Registry systemweit abdrehen. Am Server wohl eher nicht.

    Den Nagle's Algorithm kann man soweit ich weiss aber nicht global abdrehen. Wäre auch nicht gut, da das zu deutlich mehr Netzwerk-Traffic führen würde.

    0
  • N

    Ich hab mal bei MSDN geschaut. Unter Windows XP muss man wohl TcpAckFrequency auf 1 in der Registry setzen damit jedes Datenpacket sofort beantwortet wird. Jedoch gibt es das bei mir in der Registry garnicht 🙂
    *Edit*:
    Habs jetzt gefunden und geändert. Windows auch nochmal neu gestartet danach. Das Problem bleibt bestehen. Hat also nichts mit dem Delayed-ACK auf meinem Rechner zu tun.

    0
  • N

    Sonst existieren keine Ideen mehr? Ich hab absolut keine mehr.

    0
Anmelden zum Antworten