CPU-Auslastungsvergleich in FPL und ZFA. Eine kleine Studie

[Samoa]

Hallo,
ich habe einen kompletten FPL, bestehend aus 192 Zeilen, in die Profildatenbank kopiert (Fahrplanexport) und mit exakt diesen Profilen und mit gleichen Abfahrtzeiten, nur freigegeben für die entsprechende Lok, eine ZFA-Datei erstellt die also nur "Zugfahrten nach Abfahrt" enthält. Zusätzlich habe ich bei einigen FS unter "Bedingungen" allerdings noch eine Eintragung vorgenommen, um sicherzustellen, dass bei Verspätungen nicht eine zu früh gefahrene FS die verspätete oder nachfolgende länger blockiert. Diese im FPL nicht existierende Bedingungs-Karte war der eigentliche Grund für die Transformation.

Im Fahrbetrieb stellte sich heraus, dass die exakten FS-Stopp-Positionen des FPL in der Regel in der ZFA identisch waren, aber in Einzelfällen bis zu einer Wagenlänge überschritten wurden. Als Grund wurde eine höhere CPU-Auslastung bei der ZFA vermutet.

Um eine nachgelagerte Analyse dieser Auslastung vornehmen zu können, wurde das Steuerfeld der jeweiligen Automatik und die Anzeige der Systemleistung des Windows Task-Managers mit einem Camcorder vom Monitor aufgenommen und anschließend in ein Filmbearbeitungssystem ( Macrosystem Casablanca) eingespielt.
Die Auswertung geschah in der Art, dass die Anzahl und maximale Größe der Peaks ermittelt wurden, die die willkürlich gewählte Grenze von 60% CPU-Auslastung erreichten oder überschritten.
Der Unterschied zwischen den Automatiken bei einem Programm-Komplettlauf war beträchtlich:
Im FPL-Betrieb wurde der Grenzwert 8 - 25 mal überschritten,
im ZFA-Betrieb aber 92 bis 189 mal.

Mir ist vollkommen bewußt, dass diese Werte nur eine subjektive Aussage zulassen, abhängig von der Leistung des PC, der Aktualisierungsgeschwindigkeit der CPU-Anzeige, der Länge der einzelnen FS (Anzahl tangierter RMK, Art und Anzahl der Kontaktereignisse), der Anzahl der gleichzeitig aktiven FS, etc.
Aber eines ist bestätigt worden: Bei einem für den Betrachter völlig identischen Modellbahnbetrieb ist die CPU-Auslastung in der ZFA wesentlich höher.
Das hat seinen Grund natürlich darin, weil trotz ausschließlich nach Uhrzeit aufsteigend sortierter Zeileneingabe "Zugfahrten nach Abfahrt" ständig alle Zeilen abgefragt werden (hoffentlich nur die programmierte Zahl und nicht die theoretisch mögliche und nicht mehr verringerbare Zahl 999), und darüber hinaus noch weitere "Bedingungen", "Optionen" und die Matrix.

Dieser Beitrag sollte eine Anregung sein für alle, bei denen überfahrene Stopp-RMKs ein Problem sind.
Die Ergebnisse dieser subjektiven Studie sind in der Anlage im Einzelnen wiedergegeben und zugleich werden daraus abgeleitet Wünsche an die Entwickler geäußert.
Mit freundlichen Grüßen
Erhard Scghmidt-Samoa

[Frank Mondorf]

Hallo Erhard,

für die benötigte Rechenleistung wäre allenfalls das Intergral (Flache unter der Kurve) über die Rechenzeit der Kurve informativ.

Ein CPU sollte eine beauftragte Aktion so schnell wie möglich ausführen, und die Peaks bis 100% sind ein Indiz dafür, das sie es auch tut, und nichts negatives oder Bedenkliches.

Bei den T7000, T7200, T7400, T7600 Intel CPUen mit DualCore kam man z.B. mit einer einzelnen Aufgabe nicht über 50% Geamt-CPU-Last.

In den neueren Laptop-CPUen T300,T7500,T7700, T8xxx, T9xxx hat Intel dann wieder dafür gesorgt, das diese eine Aufgabe auch mehr als 50% (wie die Single-Core) Prozessoren erledigen können.

Ein interessante Auswertung, aber absolut kein Grund zur Besorgnis und kein Indiz für vezögerte Reaktionen.

Wichtig zur ZFA-Betrachtung ist noch, für den Neustart einer erst beginnenden FS/ZF lässt sie sich in der Tat etwas Zeit (es werden nur die befüllten Zeilen verarbeitet). Hoch priorisiert sind dafür die Auslösung der nächsten FS oder FolgeFS innerhalb einer ZF. Nur hier ist es wichtig, das bei Erriechen des Prüfkontakes sofort die nächste FS schaltet.

Viele Grüße
Frank

[Samoa]

Hallo Frank,
vielen Dank für Dein Statement. Irgend woran muß der Unterschied in der Häufigkeit der aufgetretenen Peaks bei FPL und ZFA ja liegen. Ich habe mir daher eine ZFA- Aufzeichnung noch einmal angesehen und festgestellt, dass mit ganz hoher Korrelation die Peaks immer nur dann auftreten, wenn im Zugfahrten Ablaufinspektor eine ZF aus der Anzeige verschwindet, und wenn zufällig 2 ZF zeitgleich enden, ist der Peak besonders hoch.
Natürlich ist es völlig richtig, dass die Abfrage von FS innerhalb einer ZF höchste Priorität haben, um die ZF nicht zu unterbrechen. Aber sollten Stopp-Signale am Ende von FS nicht auch priorisiert werden?
Mit freundlichen Grüßen
Erhard

[Markus Herzog]

Hallo Herr Dr. Schmidt-Samoa,

Natürlich ist es völlig richtig, dass die Abfrage von FS innerhalb einer ZF höchste Priorität haben, um die ZF nicht zu unterbrechen. Aber sollten Stopp-Signale am Ende von FS nicht auch priorisiert werden?

Die Stopp-Signale am Ende von FSen haben so ziemlich die höchste Priorität im Programm überhaupt. Im Zweifelsfall werden die auch in Fahrstraßen-Schaltungen etc. eingestreut.

Zu den von Ihnen geäußerten Wünschen im Word-Dokument:
zu 1)
Dies ist bereits heute so, in der ZFA laufen quasi zwei Automatikabarbeitungen parallel. Eine für die quasi-FPL und eine für die quasi-AK-Zeilen. Und es werden natürlich nur die befüllten Zeilen geprüft und sind keine AK-Zeilen da dann ist der betreffende Automatikzweig auch "tot". Dennoch ist selbst im reinen FPL-Teil der ZFA der Prüfaufwand in keinster Weise mit dem alten FPL vergleichbar, da es viel mehr Bedingungsmöglichkeiten gibt und selbst nicht eingetragene Bedingungen müssen ja zumindest soweit bearbeitet werden, dass da Programm erkannt, dass keine Bedingung eingetragen ist. Außerdem müssen auch die abgearbeiteten quasi-FPL-Zeilen immer mal wieder betrachtet werden, da es ja in der ZFA im Gegensatz zum FPL diverse Wiederholungsmöglichkeiten (nach Zeit, nach Tag bzw. spätestens nach einer Woche wieder) gibt.

zu 2)
Erstmal: ohne offenen ZF-Inspektor laufen keine ZFen d.h. also zukünftig wird dann wohl wie beim aktiven AK oder ZFA der ZF-Inspektor solange offen bleiben bis der FPL beendet wird.

Nach meinem Gefühl würde ich die Ursache für die Kontaktüberfahrungen eventuell mal beim zweiten Interface zum MA-Schalten suchen. Letztendlich bremst die langsame 6021/6051-Kombi durch ihr langsames Schaltverhalten auch den gesamten Ablauf aller angeschlossenen Zentralen. Wäre es mal möglich, dass sie Magnetartikel zum Test mal mit an die Tams MC hängen. Das kann die sicher locker noch verkraften.

Grüße
Markus

[Samoa]

Hallo Markus,
besten Dank für Deine umfangreichen Erläuterungen zum internen Ablauf bei der ZFA.
Wegen Deiner Anregung, den gesamten Betrieb auf die Tams MC zu legen, möchte ich Dir kurz meine Überlegung zu meiner Lösung darstellen:
Alles was schnell gehen muß, läuft jetzt über die Tams: Der Fahrbetrieb und die S88 Rückmeldungen. Für das Stellen der MA in FS liegt kein Zeitdruck vor - so meine Überlegung - deshalb ist dieser Job auf einem 6021/6051 verblieben. Das Schalten von FS würde auch auf der Tams einige Zeit in Anspruch nehmen, da vorhandene störrische Weichen einen verlängerten Schaltimpuls erhalten. Und wäre während dieser Schaltzeit die Tams nicht blockiert für andere Aufgaben, während das bei einem zweiten, unabhängigem System ncht der Fall ist? Oder ist diese Überlegung falsch?
Miit freundlichen Grüßen
Erhard

[Markus Herzog]

Hallo Erhard,

deine Überlegung ist nicht schlecht und ich habe früher auch so gedacht, aber dies sollte mit der Tams kein Problem auch sonst sein.
WDP sendet ja bei den meisten Zentralen den Weichen einen Ein- und einen Ausschaltbefehl, der die Schalt-Zeitdauer vorgibt (wobei viele Zentralen zu kurze Ein-/Aussequenzen selber auf Mindestzeiten verlängern).
Deine Idee ist also richtig, dass WDP in den Schaltpausen ja eigentlich wieder wichtigeres tun kann, z.B. RMKs einlesen oder Stopbefehle senden. Und genau das tut WDP u.a. während der Einschaltphasen auch. Und zumindest im Falle der Tams ist dies auch kein Problem d.h. obwohl die Tamse gerade einen MA-Einschaltbefehl bekommen hat und auf den passenden Ausschaltbefehl wartet, kann sie auch in der Zwischenzeit weitere Lokkommandos und S88-Meldungen etc. verarbeiten.

Meine Erfahrung war die Folgende: Als ich die IB genutzt habe, konnte ich eine Leistungssteigerung (im Sinne von präziserer Abarbeitung) durch den Einsatz einer 6051/6021 zum Schalten erzielen. Dies liegt daran, dass die IB im Vergleich zur Tams nicht so schnell wieder neue Befehle nach dem letzten Befehl verarbeiten kann und somit durch 6051/6021 entlastet werden kann.
Als ich auf Tams MC umgestiegen bin, konnte mit der 6051/6021 als zweites Interface keinen Unterschied zur Tams solo feststellen. Mit einer Tams MC als Hauptzentrale und IB als Zweitzentrale hat es dann ein bischen gebracht, aber eine richtige Leistungssteigerung haben erst durch dem Umstieg auf Selectrix zum Schalten und Melden erreicht. Dies liegt daran, dass bei SX quasi keine Pausenzeiten entstehen, da immer nur Schaltbefehle und keine AUsschaltbefehle gesendet werden müssen, da das gesamte Timing die Dekoder übernehmen (hat dafür dann vielleicht ein paar wenige andere Nachteile).
Wobei ich das mit den 1./2.Interface-Kombis eigentlich nicht so pauschalisieren möchte, da so viele Faktoren eine Rolle spielen (siehe unten). Von daher würde ich dir einfach raten es mal auszuprobieren (sollte ja eigentlich nur zwei Drähte sein und in WDP kann man ja alle MAs auf einmal umschalten). Kann sein, dass es was bringt, aber es kann auch sein, dass ich daneben liege.

Mich würde allerdings zum Abschätzen mal interessieren wieviele Loks beim Test so im Schnitt gleichzeitig aktiv waren und wieviele MAs deine FSen so im Schnitt haben und wieviele RMKs du so insgesamt hast.

Grüße
Markus

[Samoa]

Hallo Markus,
Dir erneut besten Dank für Deine schnellen super ausführlichen Informationen.
Ich will das mit der Tams MC allein einmal probieren.
Zu Deinen Fragen: Beim Test sind maximal 9 Loks gleichzeitig aktiv (das läßt sich ja beim ZFA Programm aus dem aufgezeichneten Zugfahrten Ablauf-Inspektor exakt ablesen), öfter auch 6-7 Loks, im Schnitt würde ich schätzen 5.
An RMKs sind 172 aktiv.
Die FS haben eine  recht unterschiedliche Zahl von MA. Ich habe die MA der ersten 19 Programmzeilen ausgezählt (10% der Gesamtzahl) und komme auf einen Schnitt von 8,5 MA, mit den Grenzwerten 3 und 21.
Mit freundlichen Grüßen

[Samoa]

Hallo Markus,
wenn ich jetzt nicht total auf dem Schlauch stehe, benötige ich für das Schalten der MA-Decoder, die alle durch einen separaten Stromkreis versorgt werden, einen zusätzlichen Booster. Diesen habe ich nicht verfügbar, insofern kann ich den vorgeschlagenen Versuch zur Zeit leider nicht durchführen.
Mit freundlichen Grüßen
Erhard

[Peter BR44]

Hallo Erhard,

finde die Test die Du durchführst sehr aufschlussreich. Was mich auch Interessieren würde mit der CPU Auslastung wäre z. B., wenn Du den Arbeitsspeicher erhöhen bzw. vergrößern würdest, ob dann die Auslastung der CPU sinkt, gleich bleibend ist oder überhaupt eine Auswirkung im Ablauf im Fahrbetrieb hat.

Gruß

Peter

[Frank Reil]

Hallo Kollegen,
ich fahre seit gut einem Jahr Windigepet 9.2 auf meiner nun gleismässig fertig ausgebauten Märklinanlage. Ich habe nun auch seit einiger Zeit das Problem, dass Fahrstraßen verzögert gestellt werden oder Züge Haltstellen überfahren und es dadurch zu Zusammenstößen kommt.

Angeregt durch diesen Artikel, habe ich nun meine CPU load unter die Lupe genommen und festgestellt, daß beim Stellen von Fahrstraßen im Bahnhofsbereich, die CPU load für mehrere Sekunden von 50 auf 100% hochgeht. Offensichtlich für die Zeitdauer, in der die Weichen gestellt werden und die Fahrstraße aktiviert wird. Ursache für die lange Stellzeit sind die motorischen Weichenantriebe im Bahnhof und die dafür notwendige maximale Stellzeit von 3000ms - WDP kann übrigens nicht mehr Stellzeit pro Weiche. Bei 3 Weichen können da schon mal über 10 Sekunden zustande kommen.

Was mich nun maßlos verwirrt ist die Tatsache, daß das System PC und Steuerung, beim Weichenstellen total ausgelastet ist. Was ist da der Flaschenhals?
Die Komunikation zur IB weil der Stellimpuls am Leben gehalten werden muß?
Die Software? - muß ja eigentlich nur den Impuls einschalten und nach 3s wieder ausschalten!

Ich kann mir nicht vorstellen, daß man eine Software so ungeschickt designen kann, daß es bei einem simplen Schaltvorgang zu einer völligen Systemauslastung kommen kann. Ich bin jeder Information dankbar, die zur Abstellung dieser unangenehmen Situation beiträgt.

Vielen Dank im Voraus,

Frank

[Frank Mondorf]

Hallo Frank,

herzlich willkomen im Forum.

Ich habe mal eine Frage: Mit welchen Decodern stellen Sie die welche motorischen Weichenantriebe?

Bei Schaltdecodern oder Decodern mit programmierbarer Schaltimpulsdauer sollten kurze Scchaltzeiten (0 oder 100ms) unter Windigipet reichen.

Wie gesagt, kurze Volllast-Peaks in Windigipet sind unbedenklich, dauerhaftes Anhlten der CPU-Last auf Anschlag natürlich nicht, hier vermute ich eher andere Gründe.

Könnten Sie mal die kurzen Schaltzeiten ausprobieren? Ob sich dadurch wirklich was an der CPU-Last ändert? Und ob die Weichen dann immer noch - wie vermutet - schalten?

Viele Grüße
Frank

[Markus Herzog]

Hallo,

ich kann auch nur raten wie Frank schon schrieb die langen Schaltzeiten für motorische WEichenantriebe entsprechenden Dekoder zu übertragen, die die nötigen Schaltzeiten selbst generieren können trotz nur sehr kurzen Puls des Digitalsystems. Die Verlängerung der Schaltzeit in WDP war seinerzeit dazu gedacht schwergängige Weichen mal mit 300ms oder so zu beaufschlagen, aber nicht dazu 3000ms Pulse zu generieren (daher ist die Grenze bei 3000ms seitens WDP eher sehr hoch anzusehen).


Grüße
Markus

[Frank Reil]

Ahh, danke.

Ich habe es fast befürchtet, dass ich mich in irgend einer Grauzone der Steuerung befinde.

Ja, bei kurzen Schaltzeiten für die magnetisch betätigten Weichen im Schattenbahnhof wird eine Fahrstraße in weniger als einer Sekunde geschalten und die CPU load hat nur einen kurzen Ausreißer Richtung max. Merkt man fast nicht.

Nein, ich kann den Dekodern keine Schaltzeiten vorgeben, da es sich um Eigenbaudekoder handelt. Ich habe die Grundschaltung der K83 mit einer H-Brücke aufgebohrt, um motorische Weichen schalten zu können.

Schade, muß ich schon wieder Hand anlegen.
...ich habe vor 5 Jahren mit einem Buch über EditsPro angefangen und alles nachgebaut was man zum Steuern einer Märklinanlage gebraucht hat. Steuerung, Handregler, Booster, Weichendekoder, S88-Module und Bremsbausteine. Die Anlage wuchs und die Ansprüche auch. Meine Störungsanfälligen Rückmeldemodule mit Stromsensor haben mich schließlich zur IB und Windigipet getrieben. Aber, komplette Steuerung wieder raus, Bremsbausteine raus, Verkabelung auf den Kopf gestellt. Die Störungen der Rückmeldemodule blieben. Da ich mit dem S88-Monitor nun aber Zugriff auf die Module hatte, habe ich nach langem Suchen die Ursache in meinen Selbstbaumodulen gefunden. Das Ganze hat mich ein Jahr zurück geworfen.
... so, und nun kommen mir die Tränen, weil ich schon wieder an meinen Dekodern rumschrauben muß. Weil ich mir wieder irgend einen Kniff ausdenken muß, wie die Dinger verzögert ausschalten können.

Ich will hier nicht unbedingt rumjammern (wo sonst würde mich jemand verstehen wenn nicht hier? Meine Frau bestimmt nicht  ), aber ich wäre wirklich dankbar wenn jemand eine andere Lösung hätte als dass ich mir neue Dekoder bauen muß.

Viele Grüße,
Frank

[FrankKu]

Hallo Frank,
nicht alles in dem Buch von EditsPro ist schlecht. Ich habe zum Beispiel die s88-Rückmelder mit Optokoppler ergänzt. Seitdem läuft alles störungsfrei.
Betreffs Deiner langen Schaltimpulse für die Weichen sehe ich die Möglichkeit, dass Du Deine MA-Dekoder behalten kannst und nur zu ergänzen brauchst. Ich habe für meine Entkupplungsgleise einen Timer aufgebaut, um den Schaltimpuls von WDP auf 6s zu verlängern. Ich denke diese Schaltung ist auch für Deine Weichen anwendbar. Probiers mal aus.

[Frank Reil]

Vielen Dank für Deinen Vorschlag.

Ich habe mich jetzt doch entschieden die Dekoder zu manipulieren. Sind ja auf meinem Mist gewachsen und sollten irgend wie ein Gedächtnis mit Timer bekommen können. Auch wenn ich es nach wie vor nicht akzeptieren kann, daß mich eine Software dazu zwingt die Hardware zu erneuern. Das ist ja fast wie bei Microsoft und Intel.

Frohes Schaffen und 100% CPU load für alle

Gruß Frank