Diskussion:Echtzeitsystem

message: Gibt es wirklich die Klassifizierung in "mittel-harte Echtzeitanforderung"? Die Erklärung ("Hier geht man davon aus, dass wenn ein System zu spät reagiert, die Ergebnisse als ungültig verworfen werden müssen.") dazu klingt stark nach einer weichen Echtzeitanforderung. Vergleiche mit Videokonferenz! - Denn hier werden Pakete, die zu spät ankommen einfach weggeworfen.
Gibt es andere Meinungen, ansonsten wäre es wünschenswert, wenn der Beitrag über die "mittel-harte Echtzeitanforderung" entfernt wird. -- Der Michl 16:16, 18. Jan 2006 (CET)
thread_title:  mittel-harte Echtzeitanforderungen 

message: Ich habe den Kleinst-Artikel Realzeitbetrieb der die DIN-Norm Sprachregelung beschrieb eingearbeitet. Ob das hier passt wird auch in diesem Löschantrag diskutiert.--inschanör 07:14, 10. Feb. 2007 (CET)
thread_title:  DIN-Norm 

message: bei prüfe auf Temperatur: cmp d,b
d enthält aber die Drehzahl, nicht die Temperatur, ich glaube da ist einfach wurde d mit t vertauscht. habs einfach mal die Kommentare geändert (nicht signierter Beitrag von 79.214.166.142 (Diskussion) 16:24, 22. Aug. 2011 (CEST)
thread_title:  Kleiner Formfehler im Assemblerprogramm unter Umsetzung, Synchrone Ansätze 

message: weiter oben wurde darüber schon diskutiert und gefragt ob das utopische Beispiel gelöscht werden soll. Ich habe mir erlaubt dies zu tun. Absolut utopisch.
Begründung 1: Ein Regelkreis besteht aus einer sensorik welche den Ist-Wert misst. Einem Regler der das Auswertet und einem Aktor, welcher den Prozess beeinflusst. Es macht überhaupt keinen Sinn Einen superschnellen Regler zu bauen, wenn das Gesamtsystem langsam reagiert. Dann ist eben die Lenkung der Flaschenhals. Die wird irgend eine Form von Mechanik haben. Da geht nanosekunden Reaktionszeit einfach nicht.
Begründung 2: Signallaufzeit: Licht macht in der ns 30cm. Was nützt es, wenn das Signal in 1 ns durch den Rechner geht aber mind. 10 ns (3m) braucht vom Radar (vorne) zur Lenkung(hinten) zu gelangen.
Begründug 3: Auch ein Analogrechner kann das nicht so schnell. Das ding muss integrieren. Analog integrieren heißt Kondensatoren laden. 1 ns -> quatsch
Begründung 4: Nehmen wir mal kurz an, das mit der ns stimmt. dann wäre die aussage: Härteste anforderungen bei Patriot trotzdem sehr merkwürdig, denn die SM3 raketen schiessen noch deutlisch schnellere ziele ab.
Indiez: Der letzte Befürworter dieser hat sich vor 3 Jahren ausgeklinkt (nicht signierter Beitrag von 87.182.3.145 (Diskussion) 20:19, 22. Aug. 2011 (CEST)
thread_title:  utopisches Beispiel Patriot-Rakete 

message: Nach einer exakten Zeiterfassung der bereitzustellenden Anwendung sind Berechnungen gemäß der Theorie der Echtzeitsysteme notwendig. 
Diesen Satz verstehe ich (bin immerhin IT-ler) in einer Definition nicht. Kann jemand den mal bitte klarer vertändlich formulieren?
--Christian.Engel (Diskussion) 11:21, 14. Sep. 2012 (CEST)
thread_title:  Harte Echtzeitanforderungen 

message: FPGAs zu erwähnen und dann vom Ansatz "dass alle Aufgaben sequentiell so schnell wie möglich abgearbeitet werden" zu sprechen halte ich für mehr als unglücklich.
Zu den Stärken von FPGAs zählt eben gerade die mögliche Nebenläufigkeit, so dass alle Aufgaben, welche keine direkten Abhängigkeiten haben eben nicht sequentiell, sondern parallel bearbeitet werden. Die Aufgabenlösung kann natürlich jeweils sequentielle Bestandteile haben aber das ist in vielen Fällen nur ein Abwägen von Hardware-Ressourcen, Rechenzeit und Größe der Hardwarestruktur (zu große Hardwareblöcke bringen keinen Gewinn mehr, da die Signallaufzeiten den Geschwindigkeitsgewinn durch Parallelisierung auffressen).
Wenn Aufgaben sich nicht nebenläufig lösen lassen, so ist dies erstmal Eigenschaft des Problems und nicht der zur Lösung verwendeten Hardware.
Ich finde auf diesen Aspekt sollte besser eingegangen werden. Ggf. könnten hierbei auch Mehrkernprozessoren betrachtet werden. Wobei diese dadurch, dass sie tendenziell mehr Hardware enthalten die nicht von den Kernen gleichzeitig verwendet werden kann, natürlich nur bedingt Aufgaben nebenläufig lösen können.
--77.187.162.185 23:46, 13. Aug. 2013 (CEST)
thread_title:  Synchrone Ansätze: FPGAs 

message: Die Definition von fester Echtzeit unterscheidet sich wohl in den beiden Beiträgen Echtzeit und Echtzeitsystem. In dem Beitrag zur "Echtzeit" steht:
*feste Echtzeit wird manchmal verwendet um eine schärfere Anforderung als bei der harten Echtzeit zu definieren. Bei der festen Echtzeit ist keine Variation auch nach unten bei der Reaktionszeit erlaubt (Isochronität). Ein praktisches Beispiel wäre ein ADC-Baustein der idealerweise mit einer fixen Taktrate arbeiten sollte (in der Realität durch Jitter des Takts eingeschränkt).
während im Beitrag des Echtzeitsystems steht:
*feste Echtzeitanforderungen: Bei festen Echtzeitanforderungen droht kein unmittelbarer Schaden. Nach Ablauf der Zeitanforderungen ist das Ergebnis der Berechnung jedoch nutzlos und kann verworfen werden.
Es wird nicht klar, ob es sich nun um eine kritischere oder um eine unkritischere Grenze handelt. Werden die Ausführungszeiten auch nach unten hin eingehalten (Isochronität), oder geht es wirklich nur um die Unbrauchbarkeit der Daten, wenn die notwendige Zeitanforderung nicht eingehalten wird?
Hilby84 (Diskussion) 16:15, 11. Dez. 2013 (CET)
thread_title:  Definition von fester Echtzeit 

message: – GiftBot (Diskussion) 10:59, 28. Nov. 2015 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekte Weblinks 

message: Der aktuelle Artikel sagt: "Computer-Programme, deren Reaktionszeiten auf Anwender-Eingaben mit Eingabegeräten (Tastatur, Maus etc.) unter 10 ms liegen, werden subjektiv als sofort wahrgenommen (siehe Usability)." Die Zahl ist nicht mit einer Quelle belegt. Weder beim Querlesen unter Usability noch in einer kurzen Web-Suche habe ich einen Beleg dafür gefunden. Ist jemandem eine Quelle dieser Zahl bekannt?
:Von Jakob Nielsen gibt es eine (englische) Quelle: "0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result." https://www.nngroup.com/articles/response-times-3-important-limits/ --91.64.117.56 17:16, 31. Aug. 2017 (CEST)
thread_title:  Quelle für 10 ms bei Eingabeverarbeitung? 

message: Zitat aus dem Artikel: "In der Praxis lässt sich eine beliebig kleine Zeitschranke mangels genügend schneller Hardware nicht immer realisieren." - Leider nicht präzise genug formuliert. Es fehlt der Beitrag der Software. Selbst auf schnellster Hardware kann es wegen ungünstig programmierter Software zu endlosen Antwortzeiten kommen. - Dies steht auch hier bereits https://de.wikipedia.org/wiki/Echtzeit, Zitat: "Durch die Hardware und Software muss sichergestellt werden, dass keine Verzögerungen auftreten, welche die Einhaltung dieser Bedingung verhindern könnten." 
Vorschlag: "In der Praxis lässt sich eine beliebig kleine Zeitschranke mangels genügend schneller Hardware oder Limitierungen in der Software nicht immer realisieren."
Meinungen?  --BauerJKH (Diskussion) 20:16, 23. Aug. 2022 (CEST)
replies: text: Passt für mich. Natürlich ist die Software gerade dann kritisch, wenn das System z.B. auf einem eigentlich nicht für harte Echtzeit ausgelegten Betriebssystem laufen soll. --PaterMcFly Diskussion Beiträge 12:07, 24. Aug. 2022 (CEST)
thread_title:  Limitierung Reaktionszeit durch Hardware und Software