Hohe CPU-Auslastung bei andauernder Abfrage

[ameise]

Hallo Zusammen,

ich habe folgendes Problem: Ich habe zwei Speicherprogrammierbare Steuerungen (SPS) aus denen ich aktuelle Maschinendaten lese. Diese Daten werden in einer Sekunde 300 mal bereitstellt, also exakt alle 1000/300 Millisekunden. Ich habe zwei Threads, denen jeweils ein Prozessorkern zugewiesen ist und die jeweils eine SPS abfragen. Wenn wieder neue Daten vorhanden sind, wird in der SPS ein bestimmtes Bit gesetzt, das ich andauernd abfrage:

Code:

  while daten_lesen do
    if bit_gesetzt then
      lese_daten;

Das klappt auch alles wunderbar und genau 300 mal pro Sekunde, aber die CPU Auslastung der beiden Kerne liegt konstant bei 100%. Das muss doch auch irgendwie anders gehen!? Nach dem Lesen könnte kurz gewartet werden (zB sleep(2) oder so), aber das ist alles viel zu ungenau :?

Vielen Dank für die Hilfe :)

[Furtbichler]

Du hast im Thread eine Schleife ohne Unterbrechung und daher rast deine CPU nonstop unter Volllast da durch. Du gibtst der CPU bzw. dem Kern ja keine Gelegenheit, etwas anderes zu machen.

Ich würde mich an deiner Stelle freuen, das Du die Daten so schnell bekommst.

[hathor]

Zitat:

Zitat von ameise (Beitrag 1181030)

Hallo Zusammen,

Code:

  while daten_lesen do
    if bit_gesetzt then
      lese_daten;

Das klappt auch alles wunderbar und genau 300 mal pro Sekunde,...
Vielen Dank für die Hilfe :)

Nach dem Abtasttheorem must Du nur alle 1,5 msec gucken.
Bau ein Delay von 1,5 bis 2 msec ein, aber nicht mit SLEEP!
Dann kommst Du auf ca. 7% CPU-Last!

http://www.delphipraxis.net/6620-delay.html

Delphi-Quellcode:

procedure Delay(Milliseconds: Integer);
var
  Tick: DWord;
  Event: THandle;
begin
  Event := CreateEvent(nil, False, False, nil);
  try
    Tick := GetTickCount + DWord(Milliseconds);
    while (Milliseconds > 0) and
          (MsgWaitForMultipleObjects(1, Event, False, Milliseconds, QS_ALLINPUT) <> WAIT_TIMEOUT) do
    begin
      Application.ProcessMessages;
      if Application.Terminated then Exit;
      Milliseconds := Tick - GetTickcount;
    end;
  finally
    CloseHandle(Event);
  end;
end;

[BUG]

Zitat:

Zitat von hathor (Beitrag 1181050)

Nach dem Abtasttheorem must Du nur alle 1,5 msec gucken.
Bau ein Delay von 1,5 msec ein, aber nicht mit SLEEP!

Wie war das mit unter 50ms ist unter Windows nichts zu garantieren?
Was ist, wenn der Scheduler mal einen anderen Task ranlässt. Das könnte schon jetzt passieren.

Wäre es vielleicht möglich, einen Microcontroller zwischen-zuschalten, der die Daten puffert?

[hathor]

Immer diese Skeptiker!

Wer zeitkritische Sachen macht, surft nicht gleichzeitig im Internet, macht keine Downloads, braucht kein Antivirus-Programm, guckt kein Video, scannt nicht die HDD (Index!), brennt keine DVD usw.

[Luckie]

Und selbst dann kann dir Windows das nicht garantieren. Wer zeitkritische Anwendungen laufen lasen will nimmt entweder ein Echtzeit OS oder einen Microcontroller. Aber da ich davon ausgehen, dass das Programm auf einen normalen PC mit Windows laufen soll, muss wohl das Programmkonzept so geändert werden, dass die ankommenden Daten gepuffert werden.

[Helmi]

Hallo,

hast du die Möglichkeit das SPS-Programm zu ändern?
Wenn ja, dann würd ich vorschlagen, du schreibst die Werte in einen Art Ringspeicher, in einen dementsprechend groß dimensionierten DB.
(Der SPS Aufwand ist da nicht groß - ist ein 6 Zeiler (indirekt übers Adressregister))

Dann könnte dein Windows-Programm in Ruhe den DB auslesen

[blackfin]

Ich würd auch vorschlagen, eine Art Hardware-Puffer zu erstellen. Bei einer solch zeitkritischen Anwendung kenne ich das von echten Geräten bisher auch nur so, dass da eine "Box" zwischen dem SPS-Gerät und dem PC hängt, die das meiste zwischenspeichert...alles andere mag zwar funktionieren, aber würde bei mir doch böse Bauchschmerzen verursachen :D

[Medium]

Das mit diesem Delay ist in einem Thread aber keine so tolle Idee. Dort ist ein schnödes Sleep schon am rechten Fleck. Diese Delay-Krücke ist ja eigentlich für den Einsatz im VCL-Thread gedacht, wo so Wartedinger imho aber ohnehin nichts verloren haben.

Auch die 50ms-Geschichte: Das gilt für Timer, weil das Message-System von Windows da problematisch wird. Der Scheduler hat damit allerdings nichts zu tun.

Blubbert doch bitte nicht gleich mit Volksweisheiten los, ohne den Anfangsbeitrag gelesen zu haben. Nach Schlagworten abtasten geht oft gut, aber nicht immer ;)


Wenn den Threads eigene Cores zugewiesen sind, und auf dem PC sonst eher wenig passiert, sind 1.5ms Zykluszeit überhaupt kein Problem, auch mit einem Sleep(1) dazwischen sollte das noch gut passen. Einzig der Fall, dass tatsächlich gelesen werden muss ist so eine Sache: Je nach dem wie die Kommunikation läuft, und was mit dem gelesenen Wert passiert, kann (wird) das arg eng. Da wäre eine Art Ringpuffer in der SPS wirklich praktisch.
Angenommen du hast eine Siemens SPS und kommunizierst (z.B. mit der libnodave) via S7-Online bzw. ISO-over-TCP Protokoll, kannst du je nach SPS bis zu 216 Bytes in einem Rutsch auslesen. Dann einfach einen Puffer-DB mit passender Größe, und ein Flag für wenn der Puffer eine Runde gedreht hat. (Puffer in der SPS nicht neu befüllen so lange das Flag ansteht! Ggf. einen zweiten Ringpuffer im Wechsel nehmen, damit auch wirklich nichts verloren geht.) So ein Paket von 200 Bytes ist praktisch genau so schnell gelesen wie ein einzelnes Byte, und man schafft sich auf PC-Seite ein wenig Luft den gelesenen Puffer zu verarbeiten. (Wenn die dennoch nicht langt evtl. über weitere Worker-Threads nachdenken.)

So lange du Einfluss auf das SPS Programm hast (es also PC-freundlich machen kannst), braucht es da eigentlich keine Zusatzhardware. Vor allem nicht, wenn die Lesethreads einen ganz eigenen Kern für sich haben.

[hathor]

Wer im ms-Bereich programmiert, muss folgende Seite und WINDOWS gut kennen:

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
.