[Vienna-pm] anmerkungen ..

[gooly at gmx.at]

Am Dienstag, 29. Mai 2007 schrieb Bernd Petrovitsch:
> 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:
>
> [...]
>
>
> 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, 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.
Das sind dann wohl Dinge, die gemeinsam synchron arbeiten müssen, ich 
habe bei mir bewusst alles so angelegt, dass ich Kette habe, immer 
eines nach dem anderen. Nach jedem Kettenglied kann ich verzweigen, zB 
zu dem nächsten und dessen 'shadow'.
>
> 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. 
interessant, das wusste ich so im Detail nicht.

> 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.

>
> 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 
ab. Du selbst unterscheidest ja in 'harte' und 'soft'.
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!

> 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 :)
> > 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.

> 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.
Du hast Recht, aber auch hier ist es eine Frage des Projektes, ob es 
akzeptabel ist - auch der läuft ja nicht Minuten lang, denke ich mal - 
oder nicht.

> 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.
In dem das niemand machen kann oder wird, weil ich mich zB im Netz 
verstecke.
> OK, man macht ein eigenes LAN, wo nur definierte Knoten mit
> definiertem Verhalten/Applikationen "mitspielen" dürfen.
Genau.
> 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. 
> [...]
>
> > > 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?
Verzeih, das ist ein bißchen so ein typische Totschalargument, 100% 
sicher ist nix! 
> 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 ;)
>
> Oder deine Toleranz ist halt: Ich lebe damit, daß das Ergebnis
> gelegentlich zu spät kommt. 
Neee, es kommt später, aber es schadet nicht, es ist ja einkalkuliert!

> Und genau das ist das Restrisiko. 
Das Restrisko bezeichnet doch eher (Wahrscheinlichkeiten von) 
Ereignissen, die das Ergebniss des Gesamtsystem verschlechtert.


Calli