TXT <-> TXC : Speed der Programmausführung

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

TXT <-> TXC : Speed der Programmausführung

Beitrag von ftDirk » 01 Jan 2016, 19:30

Ich habe es mal mit einer Programmschleife gemessen:

Ein ROBOPro Programm wird auf dem TXC deutlich schneller abgearbeitet, als auf dem TXT.

Nach meiner Messung erreicht der TXT nur ca. 78% der Ausführungsgeschwindigkeit des TXC (100%).


Wie sind eure Erfahrungen?
Gruß ftDirk

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1831
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von Dirk Fox » 02 Jan 2016, 13:35

Hallo Dirk,

das klingt ja ernüchternd...

Vielleicht sollten wir eine "Test-Suite" definieren, die der Controller durchlaufen muss, um Geschwindigkeiten zu vergleichen - änlich PCMark?
Hast Du einen Vorschlag, welche Befehle da hinein sollten? Fairerweise sollten da sicher auch ein paar arithmetische Operationen hinein...

Beste Grüße,
Dirk

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von ftDirk » 02 Jan 2016, 17:36

Hallo Dirk,

aktuell teste ich noch.

Es müssen beim TXT im Hintergrund Prozesse laufen, die den Programmablauf deutlich beeinträchtigen, auch wenn die Prozesse im Programm nicht genutzt werden.

Je nach eingeschaltetem BT oder WLAN, angeschlossener Kamera ...
... stellt sich eine andere Verarbeitungsgeschwindigkeit ein, auch wenn das Programm simpel über USB-Kabel läuft und keine Funkverbindung oder Kamera nutzt.

Ich fürchte, dass wir für den Fall einer "Test-Suite" nur dann vergleichbare Ergebnisse erreichen, wenn genau festgelegt wird, unter welchen Bedingungen/Einstellungen/Firmware-Versionen/angeschlossener Hardware/usw. der Test durchgeführt wird und welche Hintergrundfunktion aktiv genutzt wird.

Ich sehe noch kein Land ... ;)
Gruß ftDirk

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von ftDirk » 03 Jan 2016, 21:04

So, ich bin verwirrter als vorher:

Ich habe einen Hauptprogramm-Thread geschrieben, der folgenden Test macht:
- 1000x Ganzzahl-Var hochzählen
- 500x O1 ein- und wieder ausschalten
- 1000x I1 einlesen
- 1000x die 4 Grundrechenarten (+ - * /) ausführen

Der ganze Test wird noch 100x wiederholt.

In einem 2. Hauptprogramm-Thread zähle ich eine Variable während des Tests hoch, wobei eine 0,001s Pause in der Schleife liegt. Im Prinzip wird hier also eine Variable etwa jede 1 ms um 1 hochgezählt, so dass die folgenden Werte etwa Millisekunden entsprechen:

Ergebnis (mit USB-Verbindung):
TXC -> online: 3740, offline: 5076
TXT -> online: 751, offline: 52

Das verwirrt mich doch erheblich, weil:
1. Der TXT demnach doch erheblich schneller agiert als der TXC (online knapp 5x schneller, offline sogar über 97x schneller).
2. Der TXT offline viel schneller ein Programm abarbeitet als online (mehr als 14x schneller).
3. Der TXC (im Gegensatz zum TXT!) offline langsamer abarbeitet als online (online 1,36x schneller).

Im Prinzip wird das alles die meisten ROBOPro Programme nicht negativ beeinflussen, so dass ihr das eher vergessen könnt.

Wenn es aber auf die absolute Zeitdauer ankommt, die ein Programm(abschnitt) für eine bestimmte Aufgabe braucht, dann ist schon relevant, welchen Controller man einsetzt.
Anders gesagt:
Man müßte in ROBOPro eine Funktion haben, die ausgibt, auf welchem Controller das Programm gerade läuft, um Zeitabläufe je nach Controller kalibrieren zu können.

Wie könnte eine solche Funktion aussehen? Keine Ahnung aktuell.
Ich teste weiter ... 8-)
Gruß ftDirk

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1831
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von Dirk Fox » 03 Jan 2016, 21:26

Hallo Dirk,

das sieht doch schonmal nach belastbaren Resultaten aus!

Ein möglicher Messfehler könnte noch darin liegen, dass die Timer des TXC durch paralelle Prozesse verlangsamt werden. Beim TXT sollte das m.W. nicht passieren.
Als Messeinheit ist daher m.E. die Zeitanzeige einer RTC verlässlicher, die Du vor Beginn und nach Ende der Testschleife ausliest.
Dieser Fehler kann aber die unterschiedlichen Messwerte nicht verursachen - denn wenn der Timer beim TXC verlangsamt wird, müsste der tatsächliche Geschwindigkeitsunterschied noch größer sein.

Ich versuche es mal mit einer Erklärung:

- Der TXT ist offline natürlich viel schneller als online, da die Kommandos inklusive Berechnungen alle im TXT ausgeführt werden - und keine Datenübertragung vom PC zum TXT via USB stattfindet. Bei der Online-Messung fließt allerdings wahrscheinlich signifikant ein, ob Du eine USB 2.0- oder USB 3.0-Verbindung am PC nutzt, und natürlich die Geschwindigkeit des PC selbst (letzteres wahrscheinlich eher vernachlässigbar).

- Wenn der TXC offline langsamer ist als online, dann kann das nur an der Arithmetik liegen: mglw. ist die Multiplikation langsamer. Sind die Unterschiede ebenso groß, wenn Du die Arithmetik-Schleife herauslässt? (Ich vermute, dass es dann umgekehrt ist).

- Dass der TX in beiden Fällen deutlich langsamer ist, habe ich erwartet: die CPU ist weniger leistungsfähig, der Takt niedriger, die Übertragung nur USB 2.0 und insbesondere die Arithmetik offline relativ langsam.

Ich glaube nicht, dass man die Geschwindigkeitsunterschiede zwischen TXC und TXT vernünftig umrechnen kann; ganz sicher nicht in einer Formel, denn es hängt von den konkreten Funktionen ab, die ein Programm tatsächlich verwendet. Aber ein "Geschwindigkeitsindex" könnte hilfreich sein, um ein Gefühl für den "durchschnittlichen" Geschwindigkeitsunterschied zu geben.

Da ist Deine Test-Suite schon auf einem guten Weg, finde ich...

Beste Grüße,
Dirk
Zuletzt geändert von Dirk Fox am 03 Jan 2016, 23:03, insgesamt 1-mal geändert.

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von ftDirk » 03 Jan 2016, 22:32

Dirk, danke für die gute Erklärung.

Noch ein kurzes Zwischenergebnis:
Dass der TXC offline langsamer ist als online, scheint wirklich an der Multiplikation/Division zu liegen:
Wenn ich diese Rechenarten rauslasse und nur Addition und Subtraktion nehme, dann ist der TXC tatsächlich online und offline fast gleich schnell: Offline "rechnet" er jetzt sogar 1,06x schneller als online.
Im Vergleich zum TXT ändert das aber nichts.

Mit meiner Messschleife habe ich auch Bedenken:
Ist die Zeitmessung in dem 2. Thread zuverlässig?

Morgen werde ich einmal O1 mit Pause 0,001s umschalten und ein Oszi dranhalten:
Ich berichte, ob es Unterschiede in der Frequenz zwischen TXT und TXC gibt.
Sollte die Frequenz gleich sein, kann ich die aktuelle Messschleife wohl mit ruhigem Gewissen für weitere Tests benutzen.
Wenn nicht, brauche ich wirklich noch eine externe Zeitreferenz.
Gruß ftDirk

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von ftDirk » 11 Jan 2016, 18:34

So, ich habe jetzt mal ein Testprogramm "Speedtest Version 1.0" hochgeladen:
http://www.ftcommunity.de/data/download ... edtest.zip

Es benutzt zur "Laufzeitmessung" eines Codeabschnitts, in dem mehrfach nur eine Ganzzahl-Variable hochgezählt wird und der Eingang I1 abgefragt wird, einen 2. Thread, der eine Variable mit eingelagerter Pause 1ms hochzählt.

Diese Art der "Messung" ist eher beliebig, kann aber die Controller sicher voneinander unterscheiden.
Darauf kam es mir an, also auf eine Funktion, die die ft-Controller voneinander unterscheiden kann.

Ich würde mich freuen, wenn jemand diesen Speedtest mal auf dem ROBO Interface und dem Intelligent Interface laufen läßt, und die Werte hier postet.
Dann könnte man sicher alle 4 Controller voneinander unterscheiden.


Wie bin ich eigentlich auf diese Sache gekommen?

Ich hatte bei meinem DCF77-Decoder:
http://www.ftcommunity.de/data/download ... _forum.zip
... festgestellt, dass die zeitbestimmende Schleife z.B. beim TX funktioniert und dann aber NICHT beim TXT und umgekehrt.
Das Programm kann ich also nur dann für verschiedene Controller auslegen, wenn ich erkennen kann, auf welchem Controller es läuft. Dann kann ich zeitkritische Routinen für unterschiedliche Controller anpassen.
Gruß ftDirk

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von ftDirk » 12 Jan 2016, 18:46

@elektrolutz:
auf RIF und II gibt es keine Displays an den Controllern. Sind die Werte dann überhaupt brauchbar zu vergleichen?
Zumindest müßte man ja die Online-Werte sehen können, oder?

Wie kriegt man denn Rechenergebnisse aus einem RIF oder II raus? Z.B. über RS232 senden oder binär mit LEDs?
Ich kenne mich mit den älteren Controllern leider nicht genügend aus.
Könnte jemand das Programm mal auf einem RIF oder II laufen lassen?
Gruß ftDirk

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von ftDirk » 13 Jan 2016, 19:47

@elektrolutz:
Wenn man die Display-Befehle ändern bzw. löschen muss, sind dann die Online-Ergebnisse immer brauchbar vergleichbar?
Ich denke: Ja, da die Ausgabebefehle erst NACH Ende der Messschleife eine Rolle spielen.

Man dürfte aber nicht z.B. einen weiteren Thread im Hauptprogramm starten, o.ä.
Gruß ftDirk

hamlet
Beiträge: 332
Registriert: 12 Jan 2011, 21:41

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von hamlet » 13 Jan 2016, 21:56

Hi ftDirk,
ich hab mir gerade Dein SpeedTest Programm angeschaut.
Früher war es so, dass das RoboPro Standard-Warten-Element grundsätzlich eine Millisekunde aufgeschlagen hat, auf dem TX,... den TXT gab's da noch nicht: 0,001s -> 2ms, 0,5s->501ms, ... (Wie es sich jetzt mit der 4.2.3 Firmware verhält, weiß ich leider nicht.)
Ich hatte mir deshalb basierend auf einer Timer-Variablen ein eigenes Wait-Unterprogramm geschrieben, das die am Eingang gesetzte Anzahl von Millisekunden wartet.
TimingTools.rpp
Unter obigem Link findest Du auch noch ein anderes Unterprogramm "chkT" (CheckTime). Es lässt sich an beliebigen Stellen im Programmablauf einfügen und es stellt am Ausgang die Anzahl der verstrichenen Millisekunden seit dem letzten Aufruf zur Verfügung.
Auf dem TX haben mir diese beiden Tools bei Performance-Messungen immer gute Dienste geleistet. Ich hoffe, dass sie mit der 4.2.3 Version immer noch zuverlässig laufen. Beim TXT bezweifele ich das augenblicklich, ... siehe auch folgendes Thema "TXT Zeitmessung fehlerhaft". Aber zumindest für größere Zeitintervalle sollte die Messung auch auf dem TXT einigermaßen brauchbar sein.

Vielleicht ist es auch mal interessant einfach eine leere Schleife als Referenz auszumessen. Bei sehr alten RoboPro-Versionen hat ein Schleifendurchlauf 2ms (oder sogar 3ms(?)) verballert. Ja, eine leere "n=500"-Schleife benötigte eine ganze Sekunde. Das ist zum Glück nun nicht mehr so lahm.

Wieso machst Du die Zeitmessung auf einem separaten Prozess? Ich hab den (vagen) Eindruck gewonnen, dass zusätzliche Prozesse auf dem TX Performance-Fresser sind. Leider kann ich das nicht quantifizieren, weil ich das nie näher untersucht habe. Aber was spricht dagegen, die Zeit auf dem gleichen Prozess zu messen? Je einfacher die Messung desto besser. Vielleicht hilft dir ja obiges "chkT"-Tool bei den Messungen.
Beste Grüße,
Helmut

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von ftDirk » 13 Jan 2016, 23:09

Hi Helmut,

ja, deinen Beitrag "TXT Zeitmessung fehlerhaft" hatte ich schon gesehen.

Das Speedtest Programm ist nur ein Versuch, die Controller unterscheiden zu können.
Es gibt aber keinen Hinweis auf eine absolute Geschwindigkeit der Programmabarbeitung.

Ich habe mal mit dem TXT eine simple Schleife genommen: O1 ein, 1ms Pause, O1 aus, 1ms Pause.
Halte ich dann ein Oszilloskop an O1, sehe ich:
a. Keine symmetrische Rechteckspannung (Tastverhältnis ca. 30:70)
b. Keine regelmäßige Rechteckspannung
c. Die Frequenz ist erheblich niedriger als zu erwarten

Ich habe es danach aufgegeben, eine zuverlässige Aussage über die absolute Geschwindigkeit des TXT machen zu können.
Gründe:
- Das Betriebssystem ist offenbar hochgradige interruptgesteuert
- Die Geschwindigkeit ist auch abhängig von aktiven Kommunikationsmodulen (BT, WLAN)
- Die Geschwindigkeit ist vom Anschluss der USB-Kamera abhängig (ohne deren Nutzung!)
- ...

Selbst wenn man einen Codeabschnitt mit einer externen Referenz vergleichen würde (Idee: DCF77-Signal, z.B. 800/900ms-Pause), wäre die Messung nur bei exakt gleichen Bedingungen (z.B. was ist an Schnittstellen ein-/ausgeschaltet ...) reproduzierbar.

Also bin ich dazu gekommen, eine Funktion zur allgemeingültigen Unterscheidung der Controller zu suchen.
Damit kann ich ein zeitkritisches Programm so anpassen, dass es "automatisch" auf dem TX und TXT läuft.
Gruß ftDirk

thkais
Beiträge: 381
Registriert: 31 Okt 2010, 21:45

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von thkais » 14 Jan 2016, 15:10

Hallo ftDirk,

die Abfrage der Ein- und Ausgänge ist für eine Performance-Messung m.E. nicht geeignet, da die Ein- und Ausgänge bei allen Controllern mit einem 10ms-Raster abgefragt bzw. aktualisiert werden. Intern reduzieren sich Zugriffe auf den I/O auf reine Speicherzugriffe, weil die tatsächliche Hardware-Abfrage im Hintergrund stattfindet (vgl. hierzu die "Transfer-Area", die z.B. bei den C-Programmier-Paketen benutzt wird).
Bei einer (vergleichsweise) komplexen "Firmware" wie Linux (TXT) hat man natürlich auch ganz andere Einflüsse als bei einem relativ schlanken embedded-OS wie beim TX. Insofern ist ein Vergleich beider Systeme kaum möglich.
Wie man bei deinen Messungen gesehen hat, scheinen hauptsächlich mathematische Funktionen tatsächlich einen nachvollziehbaren Einfluss zu haben.
Gruß
Thomas

ftDirk
Beiträge: 71
Registriert: 28 Okt 2011, 18:28

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von ftDirk » 14 Jan 2016, 22:48

Hallo Thomas,

ja, dass die IO-Abfrage "nur" ein Speicherzugriff ist, ist mir (zumindest beim TX) klar.
Auch beim TXT wird eine Eingangsabfrage ja wohl nicht in "Echtzeit" erfolgen.

Mir geht es nicht darum, den TX mit dem TXT zu vergleichen im Sinne einer Bewertung: Wer ist besser?

Ich hatte einfach das Problem, dass eine zeitrelevante Schleife entweder beim TX oder (nach Anpassung) beim TXT funktioniert.
Ich müßte also das Programm eigentlich 2x vorhalten, eben für jeden der beiden Controller.

Jetzt kann ich die beiden Controller per Software unterscheiden, und das Programm verzweigt je nach Controller in die passende zeitrelevante Schleife.
Damit ist für mich das Problem erstmal gelöst.

Offen bleiben aber noch Fragen für zukünftige Programme:
- Kann man mit Warte- oder Tick-Befehlen zuverlässig Aufgaben in festgelegtem Abstand ausführen?
- Wenn ja: Wie sieht der Code dafür aus? (Wer schreibt ein Programm, das eine Lampe auf dem TXT und TX unabhängig von Einflüssen (WLAN, BT, Kamera) GENAU alle 3s für 0,5s einschaltet?)
- [Geht das systembedingt überhaupt?]
Gruß ftDirk

hamlet
Beiträge: 332
Registriert: 12 Jan 2011, 21:41

Re: TXT <-> TXC : Speed der Programmausführung

Beitrag von hamlet » 18 Jan 2016, 19:58

Hallo TXT Speedsters,
Ich hab dem TXT nochmal ein bisschen auf den Zahn gefühlt. Mit einer im Vergleich zum TXT atom-genauen Zeitbasis: Einem Encoder-Motor alter Bauart im Leerlauf gespeist durch den TXT 9V-Ausgang. Das ergibt bei mir am Counter-Eingang "C1" des TXT ein feines Rechteck-Signal von (380+-2)Hz, wenn der Motor sich einmal warmgelaufen hat.

In folgendem Programm
TxtTimeWarp.rpp
hab ich einfach die benötigte Zeit für eine Schleife über 380 vom TXT mit dem Warten Element detektierten Inkremente am Counter-Eingang gemessen.
Erwartet habe ich bei ~380Hz eine Zeit um 1s. Das Resultat sind sauber reproduzierbare (3800+10)ms=3.8s.

Ersetzt man in der Schleife das "WaitC1" durch ein Standard "0,001s"-Warten-Element, ein 1ms-"WaitTmr"-(Wait implementiert basierend auf klassischer Timer –Variablen) oder ein 1ms-"WaitTck" (Wait implementiert basierend auf neuem Ticker-Eingang), erhält man in allen Fällen das gleiche Ergebnis auf dem TXT: 3.8s

=> Der TXT ruft den RoboPro Code im Schnitt alle 10ms auf. Round Robin Scheduling? Ich habe aber die starke Vermutung, dass er das nicht sonderlich regelmäßig tut. Falls, irgendein System-Thread etwas Wichtigeres zu tun gedenkt, kann der Abstand zwischen zwei Updates eines Warten-Elements durchaus länger dauern. Bislang hab ich da bis zu 50ms beobachtet.
=> Wenn man auf dem TXT auf ein externes Ereignis – Universal-Eingang, schneller Zähl-Eingang oder auch einen Timer – wartet, so wartet man im Schnitt 10ms (sporadisch bis zu 50ms) auch wenn man z.B. den Timer auf eine Millisekunde eingestellt hat.

Auf dem TX, der den RoboPro-Code schön regelmäßig im 1ms-Takt ausführt, sind die Ergebnisse wie gehabt (Hier laufen die "WaitTck" und "ChkTck" wegen des warum auch immer nicht unterstützten Ticker-Eingangs nicht => "ChkTmr" und "WaitTmr" verwenden und die Ticker-Eingänge temporär durch irgendwas anderes ersetzen):
  • Ziemlich genau 1000ms für 380 Mal Warten auf den Counter-Update, bei anliegendem 380Hz Rechteck.
  • 380ms für 380 1ms-"WaitTmr" Aufrufe
  • 760ms für 380 Aufrufe des Standard-"0,001s"-Warten-Elements. RoboPro schlägt hier eine Millisekunde beim Warten auf.
=> Tja, Bezüglich der Reaktivität bzw. des Real Time Verhaltens ist der TXT im Vergleich zum TX eher ein Rückschritt. 50ms Aussetzer finde ich jedenfalls nicht akzeptabel. Das hört und sieht man. Ich hoffe, dass da die ft-Entwickler noch was drehen können. … Schau'n mer mal.

Beste Grüße,
Helmut

Antworten