From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA06390; Fri, 23 Apr 2004 22:20:35 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA06313 for ; Fri, 23 Apr 2004 22:20:34 +0200 (MET DST) Received: from hirsch.in-berlin.de (hirsch.in-berlin.de [192.109.42.6]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3NKKXjq021082 for ; Fri, 23 Apr 2004 22:20:33 +0200 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from hirsch.in-berlin.de (localhost [127.0.0.1]) by hirsch.in-berlin.de (8.12.11/8.12.11/Debian-3) with ESMTP id i3NKK1JA012403 for ; Fri, 23 Apr 2004 22:20:33 +0200 Received: from first.UUCP (uucp@localhost) by hirsch.in-berlin.de (8.12.11/8.12.11/Debian-3) with UUCP id i3NKF4ld012022 for inria.fr!caml-list; Fri, 23 Apr 2004 22:15:04 +0200 Received: by first.in-berlin.de via sendmail from stdin id (Debian Smail3.2.0.114) Fri, 23 Apr 2004 22:10:50 +0200 (CEST) From: oliver@first.in-berlin.de (Oliver Bandel) Date: Fri, 23 Apr 2004 22:10:50 +0200 To: caml-list@inria.fr Subject: [oliver: Re: [Caml-list] Real Time Ocaml] Message-ID: <20040423201049.GI271@first.in-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; oliver:01 in-berlin:01 oliver:01 bandel:01 caml-list:01 caml-list:01 2004:99 basile:01 runtime:01 doable:01 slower:01 barrier:01 ocamlopt:01 slower:01 predictable:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk ----- Forwarded message from oliver ----- To: Brian Hurt Subject: Re: [Caml-list] Real Time Ocaml On Mon, Apr 19, 2004 at 07:20:38PM -0500, Brian Hurt wrote: > On Fri, 16 Apr 2004, Basile Starynkevitch wrote: > > > I do not think that re-coding the Ocaml runtime system for hard > > real-time performance is really realistic (it is doable, but it is a > > big task, requiring significant expertise), and I suspect that the > > resulting system would be slower than today's Ocaml, and will perform > > worse. Real-time garbage collection is tricky and costly (perhaps even > > needing some kind of read barrier). If you recode the Ocaml GC, you > > either have to recode the bytecode interpreter or heavily change some > > tricky parts of the ocamlopt native code generator. > > > > First off, having worked in the realtime world, realtime does not mean > fast. Quite the contrary, often. What realtime means is that I can set > deadlines, that a certain amount of work needs to be done within a given > time, and can test and prove that the work will, indeed, be done. Soft > realtime generally means that missing a deadline, while bad, is not > catastrophic. Examples include music and video recording/playback. > Missing a deadline means a skip. Hard realtime means that there are > catastrophic consequences for missing a deadline- generally, lawyers get > involved if you miss the deadline. An example here is the brake > controller on your car. Slower isn't the problem, so long as it's a > constant slower. It's large differences in time between "common case" and > "worst case". [...] Hard realtime conditions are not "constant delay times". It is: it's completely deterministic and fitting into the time constraints! It can be constant as well as not constant time delay of an answer. This does not make a distinction here. A system is a hard-realtime system, when it behaves completely predictable in respet to delay-time maxima. And yes, when you write programs on a realtime OS and did not explicitly forsee limits that fit into your perceptional harmony, you may wait for a long time to get an answer (because priority of your task may be very low, if not explicitly asking for higher priorities with hard realtime conditions beyond millieconds...). > > The only thing non-realtime in Ocaml is the garbage collection. even purte C-code does not automatically fit into hard-realtime categories, when the underlying OS does not provide hard realtime possibilities! SO the programming language can't help in realtime issues, if the OS does not provide realtime functionality. But the language may destroy realtime issues provided by an OS. Ciao, Oliver P.S.: So called soft realtime is: statistically it is very unlikely/uncertain that the realtime condition will not be fitted. So in soft realtime systems, most of the time the time-constraints are matched, and the job is well done, but to a certain amoount of cases the realtime conditions were failed. So, it's a statistical issue here: nearly 90% or nearly 99% or nearly 99.99999% of all cases are ok, but some rare cases the condition may be not fitted. (And undera high system load, the situation may get much more worse! Maybe only 50% of the cases fit into the realtime conditions... or the system may even break down completely.) In hard realtime the time-constraints must be ALWAYS fitted/matched, so that 100% of all cases where a realtime condition must be fitted into, will and have to be fitted! So, if you have 0.00000000000000001 % of all cases missing the realtime condition, your system is NOT a system that can be viewed as a hard-realtime system. Hard realtime systems have to fit the time-conditions ALWAYS, which means 1 out of 1, 10 out of 10, 10000000000 of 10000000000 cases and \infty of \infty cases -> ALWAYS and EVER. In soft realtime systems, it's sufficient, if the conditions were met "often enough", which means to a certin degree of likelyhood/certainty. 1 out of \infty is no problem in mathematics, where you get your limes nevertheless. But in hard realtime systems this is *absolutely* failure. 1000 out of 100000 is no problem in soft realtime. ----- End forwarded message ----- ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners