[Vienna-pm] anmerkungen ..

[Bernd Petrovitsch]

On Tue, 2007-05-29 at 16:32 +0200, gooly at gmx.at wrote:
> Am Dienstag, 29. Mai 2007 schrieb Bernd Petrovitsch:
[...]
> > 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).
> Ok, aber meine Notwendigkeit ist 'so hart' nun nicht, die 
> Anwendungsbeispiele sind Laserschneidemaschienen, da kann ich es 
> gemütlicher angehen..

Gut, dann hast im Prinzip ein Soft-Realtime-System.

[...]
> > Und man setzt auch besser 10MBit-Hubs statt 10GBit-Switches ein 
> > - es interessiert niemanden, daß das vielleicht viel langsamer als
> > ein Switch ist.
> ok, aber wenn man diese Beweisnotwendigkeit nicht hat.

Soft-Realtime.

> > Im engeren Sinn, nein. Ich wollte nur sichergehen, daß wir "Echtzeit"
> > gleich definieren.
> Naja, was Echtzeit ist, hängt doch von den Erfordernissen des Projektes 

Der Begriff "Echtzeit" ist fest definiert - unabhängig vom Projekt. *Ob*
Dein Projekt das Wort "Echtzeit" verwenden sollte, ist die Frage.

> ab. Du selbst unterscheidest ja in 'harte' und 'soft'.

Ja, beides sind echte Untermengen von "Echtzeit", um da nochmal eine
sinnvolle Unterteilung zu haben. IIRC gab/gibt es auch eine dritte, aber
die hab ich verdrängt.

> Versteh mich nicht falsch, ich widerspreche nicht so sehr dem Inhalt, 
> als vielmehr Deiner 'strictness'. Die Unterscheidung zwischen hart und 
> soft ist nicht immer eindeutig!

Wie bei vielen "Prosa-definierten" Konzepten.
Aber ich seh' bei der von mir gebrachten Unterscheidung wenig
Mißverständlichkeit bzw. Unklarheit, d.h. ich hab noch nichts erlebt, wo
es nicht relativ klar ist.
Aber ich lerne gerne dazu.

> > 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.
> ok! Aber Perl hatt ja dann noch den Vorteil, man kann es in C wandeln :)

Ja, und dann gehen wir alle aufgerufenen Libraryfunktionen
kontrollieren.

> > > 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). 
> Auch wenn das ein Streit um des Kaisersbart sein könnte, Zielwerte mit 
> definierten Toleranzen halte ich für die sinnvollere Ausdrucksweise. 
> Sie trennt deutlich das erwartete, zeitliche (Normal-) Verhalten eines 
> Systems von den unerwarteten aber akzeptierten oder erwarteten 
> Schwankungen oder Verzögerungen.

Ja, das mag bei Best-Effort-Systemen (das sind alle, die nicht "Echtzeit
sind) praktischer und sinnvoll sein.
Bei Echtzeitsystemen interessiert der "erwartete Normalfall" nicht
wirklich, weil man so ein System auf den Worst-Case dimensioniert (und
wenn im Normalbetrieb 90% der Kapazität nicht ausgenützt werden, weil
man sie nur für Extremsituationen braucht, dann ist es halt so. Immer
besser als mehr Flugzeuge, die wenig kontrolliert herunterkommen).

> > 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.
> Du hast Recht, aber auch hier ist es eine Frage des Projektes, ob es 

Es ist immer eine Frage des Projektes, *ob* es eine Echtzeit-System (und
wenn ja, ob "hart2 oder "weich") ist oder nicht und wieviel "Fehler"
toleriert werden können (sowohl Fehler im Zeit- wie im Wertebereich).
Wir können auch drüber streiten, ob es noch ein "Fehler" ist, wenn die
Ungenauigkeit eh einkalkuliert ist.

Nur wenn jemand kommt und sagt, "wir haben da ein Echtzeitprojekt und
programmieren es in perl" dann sagt mir meine Erfahrung, das >90% der
Leute nicht wissen, was sie da sagen (Anwesende natürlich ausgenommen)
und da das Buzzword benützen, weil es cool klingt und $KUNDE (oder
sonstwen) beeindruckt.

> akzeptabel ist - auch der läuft ja nicht Minuten lang, denke ich mal - 
> oder nicht.

Ich weiß nicht, was der Worst Case ist. Ich weiß nicht mal, ob es jemand
weiß.

[...]
> > 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.
> Eigentlich mach ich ja genau das mit meiner Kette. Nur am Anfang dieser 
> Kette wartet 'der Erste' auf die Daten, um ihnen den Zeitstempel zu 
> verpassen und dann werden im 'Zweiten' daraus 1-Min-Bars, der wartet 
> auf die 'Zeit' + Toleranz von 1,2 Sek um die Daten mit dem 
> Zeitstempel :00 noch mitzunehmen.
> :) Zielwert ist die genaue Minute :00, das ist aber unrealstisch und ich 
> brauch eine Toleranz von 0.5 Sek, die durchaus akzeptabel sind.
> Ist auch leichter und verständlicher zu Programmieren. 

Gut so, wenn es bei Dir eine so "einfache" Lösung gibt.

[...]
> > Ja, aber woher weiß ich *a priori* *verläßlich*, daß die Zeit
> > eingehalten wird?
> Verzeih, das ist ein bißchen so ein typische Totschalargument, 100% 
> sicher ist nix! 

Aber es definiert das Ziel sehr klar (und um der Erkenntnis Willen
bringe ich einfache und klare Aussagen wohl wissen, daß es nicht die
ganze Wahrheit bis ins letzte ist). Und es gibt Situationen, da will man
keine Kompromiß eingehen: Würdest Du in einen Airbus (oder Boeing
oder ...) steigen, wo schon in der *Spezifikation* das Wort "Restrisiko"
oder "in 99,9% aller Fälle" vorkommt?

> > Ein Lasttest ist jedenfalls viel zu wenig - auch wenn er (angeblich)
> > die x-fache Last simuliert.
> Man kann sich nur auf 'wissbares' vorbereiten und auch hier wird man 
> ganz bewuß gewisse Risiken akzetieren: Was ist wenn jemand einbricht 
> und den pc klaut? Auf einmal ein ganz schlechtes Echtzeitverhalten ;)

Ja, das war mit der definierten Fehlerhypothese gemeint. Niemand kann
(im Moment) ein System bauen, daß alle Fehler handlen kann (und wenn,
ist vermutlich das System zu nix wirklich brauchbar;-). D.h. man muß
sich die Fehler definieren, die man überleben will.
Wenn die Fehlerhypothese der Realität widerspricht, dann hat man ein
seriöses Problem.

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