[Vienna-pm] anmerkungen ..

Bernd Petrovitsch bernd at firmix.at
Tue May 29 01:57:08 PDT 2007


On Tue, 2007-05-29 at 09:00 +0200, gooly at gmx.at wrote:
> Am Montag, 28. Mai 2007 schrieb Bernd Petrovitsch:
> > On Mon, 2007-05-28 at 19:56 +0200, gooly at gmx.at wrote:
> > > Am Montag, 28. Mai 2007 schrieb Peter J. Holzer:
[...]
> > > > Wenn Du ein hartes Echtzeitsystem brauchst, solltest Du
> > > > wahrscheinlich sowohl um General-Purpose-Betriebssysteme (Linux,
> > > > Windows, ...) als auch um Perl einen großen Bogen machen.
> > >
> > > Warum Linux nicht, warum Perl nicht? Laut einer Untersuchung (aus
> > > dem
> >
> > Weil es keine Garantien über Rechtzeitigkeit gibt, d.h. Garantien daß
> > bestimmte Funktionen/Subsysteme/... maximale Ausführungszeiten haben.
> Aber das kann (muss) man dann doch so programmieren - egal in welcher 

Das ist eine notwendige, aber nicht hinreichende Bedingung.

> Sprache, auch in Perl, oder?

Perl hat - wie jede Interpretersprache - das zusätzliche Handikap, daß
Du einen echtzeitfähigen Interpreter drunter brauchst.
Und wenn unter den Applikationen ein Kernel läuft, dann müssen die
Systemcalls auch zeitliche Vorgaben einhalten.
Ja, es gibt POSIX RealTime Zeugs im Linux-Kernel. Nein, für harte
Echtzeit ist das unbrauchbar, da mußt Du schon z.B. RTAI verwenden (für
die Echtzzeittasks).

> Gut, denkbar sind Systeme, die so schnell sein müssen, dass man zum 
> Maschinencode greift, aber das ist eine andere Geschichte, und für mich 

Da gibt es aber nur wenige Spezialfälle, wo Assembler wirklich
nennenswert schneller ist wie irgendeine kompilierte Hochsprache. Bei
Interpretersprachen (perl, JVM, ...) hängt es dann auch noch vom
Interpreter drunter ab.

> nicht notewendig. Aber ich sehe keinen Nachteil Perls gegenüber anderen 
> Sprachen, im Gegenteil, es ist sogar schneller als mach andere moderne 
> Hoichsprache, wie zB Java.

Es geht nicht um die Geschwindigkeit der Ausführung (die ist im Prinzip
irrelevant solange die maximale Dauer garantiert werden kann), sondern -
bei harter Echtzeit - darum 100% zuverlässige Aussagen (im Idealfall
beweisbar) über das Verhalten in der Zeit zu machen (unter einer
gegebenen Fehlerhypothese).

Anderes Beispiel: Es gibt das RTnet Projekt. Da bauen Leute
Echtzeit-Kommunikation über handelsübliches Ethernet mit CotS Hardware.
Auf Ethernet wird CSMA/CD CSMA/CA o.ä. eingesetzt. Nur sind Kollisionen
wenig deterministisch, ergo dürfen die nicht passieren. Was macht man?
Man legt statisch fest, wer wann sendet.

Frage: Setzt man dann Hubs (Multi-Port-Repeater) oder Switches
(Multi-Port-Bridges) ein und warum?

Antwort: Man setzt *selbstverstäblich* nur Hubs ein, weil Switches
store-and-forward machen und das in der Zeit nicht kontrollierbar ist.
Und man setzt auch besser 10MBit-Hubs statt 10GBit-Switches ein - es
interessiert niemanden, daß das vielleicht viel langsamer als ein Switch
ist.

> > > Netz) aus Deutschland ist Perl (auch Python und so) viel schneller
> > > programierbar als zB C oder C++ ist aber parktisch genauso schnell
> > > in der Ausführung wie C (später kann man ja dann noch C erzeugen,
> > > wenn man möchte). In C muss man aber jeden Kleinkram selber machen
> > > und C++ und Java sind etwas für Romaschreiber - nix für Faule ;)
> >
> > Das hat alles mit "Echtzeitfähigkeit" nach akademischer Definition
> > (und damit der wahren) nichts zu tun.
> > Das Problem, daß die Welt mit dem Begriff "Echtzeit" hat ist, daß er
> > in den letzten Jahren von diversen Ahnungslosen und/oder Ignoranten
> > als Marketing/Sales-Buzzword für "sofort", "möglichst schnell",
> > "unverzüglich", u.ä. technisch wenig sinnvolle Adjektive vergewaltigt
> > wurde.
> Das ist klar! Hat aber nicht mit der Programier-Sprachwahl zu tun?

Im engeren Sinn, nein. Ich wollte nur sichergehen, daß wir "Echtzeit"
gleich definieren.
Im weiteren Sinn: Natürlich. Schließlich muß *jeder* Aspekt
echtzeitfähig sein. Wenn die ach-so-tolle-Programmiersprache transparent
(und damit zwingend *unkontrollierbar*) z.B. Garbage Collection macht,
dann ist sie dafür unbrauchbar.

> Und wie bei jeder technischen Spezifikation kann man nie einen genauen 
> Zielwert angeben, sondern immer nur einen zusammen mit einer zu 
> erreichenden Tolleranz! Auch das ist in Perl erreichbar: Je nach 

Tja, bei Echtzeitsystemen *sind* die genauen Zielwerte vorgegeben und
die Toleranz ist - bei harter Echtzeit - idR 0 (andernfalls addiert man
die Toleranz gleich zum Zielwert und ist bei Toleranz 0). Und dann muß
man das gesamte System so designen, daß die Zielwerte auch eingehalten
werden.
Deswegen löst das Einführen eine Toleranz in der Zeit nicht das Problem
sondern bestenfalls zum a posteriori Messen des "Restriskos" benützt
werden (wenn überhaupt).

Und wenn das nicht geht, kann man das System eben nicht bauen. Entweder
kann man mit anderen Zielwerten leben (die dann auch wieder als feste
Vorgabe betrachtet werden) oder man läßt es (und das Projekt ist tot).
Es gibt - akademisch betrachtet - keine andere Lösung.

> Schnelligkeitsanforderung muss man halt auf das Gesamsystem schauen, 
> oder wie Du sagt Hardware bewerfen :).

Pures Hardware draufwerfen bringt keine zeitlichen Garantien sondern
reduziert nur das Restrisiko.

> Und wenn Perl dann nicht schnell genug ist, ist wahrscheinlich auch C 
> nicht schnell genug - auf diesem System.
> Und wie gesagt, Perl ist praktisch so schnell wir C. Das Problem wäre 
> also so nicht Perl.

Ich glaube nicht, daß z.B. der Garbage-Collector in perl irgendwelche
zeitlichen Garantien gibt (und die perl Gurus werden das korrigieren,
wenn es nicht stimmt).
Wie willst du da Aussagen über das Verhalten in der Zeit treffen. Da
helfen auch "Toleranzen" nichts, weil du die Einhaltung derselben auch
nicht garantieren kannst.
Es gibt nicht im Linux-Kernel, daß zeitliche Angaben über die Dauer der
Systemcalls macht. Wenn jemand z.B. per Floodping dermaßen viele
Hardware-Interrupts erzeugt, daß alles viel länger braucht, wie willst
du das einkalkulieren.
OK, man macht ein eigenes LAN, wo nur definierte Knoten mit definiertem
Verhalten/Applikationen "mitspielen" dürfen.
Und alle hunderte andere Möglichkeiten, IRQ-Storms zu erzeugen, mußt du
jetzt auch noch lösen.
BTW ist das mit ein Grund, warum Interrupts bei Echtzeitsystmen
normalerweise vermieden werden und Polling das Mittel der Wahl ist.

[...]
> > Tja, der Hund bei Echtzeitsystemen als solchen ist, daß Du nur das
> > gesamte System dann und nur dann echtzeitfähig bekommst, wenn Du ganz
> > unten damit anfängst.
> > Wenn nicht, dann muß du mit dem Restrisiko leben. Das mag größer oder
> > kleiner sein und Du kannst es mit Hardware bewerfen, aber Du wirst es
> > mit Hardware nicht erschlagen können.
> Naja, es ist erschlagen, wenn Du Toleranzen definierts und innerhalb 
> derer bleibst..

Ja, aber woher weiß ich *a priori* *verläßlich*, daß die Zeit
eingehalten wird?
Ein Lasttest ist jedenfalls viel zu wenig - auch wenn er (angeblich) die
x-fache Last simuliert.

Oder deine Toleranz ist halt: Ich lebe damit, daß das Ergebnis
gelegentlich zu spät kommt. Und genau das ist das Restrisiko.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services



More information about the Vienna-pm mailing list