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 RAA03127; Fri, 16 Apr 2004 17:12:33 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA01977; Fri, 16 Apr 2004 17:12:32 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3GFCRYM023489; Fri, 16 Apr 2004 17:12:29 +0200 Received: from [192.168.1.200] (ppp113-79.lns1.syd3.internode.on.net [150.101.113.79]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i3GFCOZq085746; Sat, 17 Apr 2004 00:42:25 +0930 (CST) Subject: Re: [Caml-list] Real Time Ocaml From: skaller Reply-To: skaller@users.sourceforge.net To: Erol Akarsu Cc: Basile Starynkevitch , Brian Hurt , caml-list In-Reply-To: <20040416123348.74144.qmail@web12405.mail.yahoo.com> References: <20040416123348.74144.qmail@web12405.mail.yahoo.com> Content-Type: text/plain Message-Id: <1082128344.20063.101.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 17 Apr 2004 01:12:24 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 basile:01 ebusiness:99 latency:01 standardised:01 latency:01 fragment:01 9660:01 glebe:01 ocaml:01 ocaml:01 imho:01 nsw:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 2004-04-16 at 22:33, Erol Akarsu wrote: > Hello Basile, > What I was thinking that with real-time ebusiness we > should achieve same performance as current > softswitches > . That means whenever you make phone call, you call > should be connected in say 1 seconds, maximum = 2 > seconds. In ocaml case, Let's say one time 500 users > are making call simultaneously and at some point Ocaml > starts GC algorithm. Maybe, next user will have some > waiting time because of GC overhead. This kind of telecommunications is not true real time. I actually worked on precisely this kind of code. Latency making connections is not an RT issue. In fact it is common, standardised, practice to simply dump connections under load -- which is known as 'call gapping'. You do need overal performance, but there is no critical need to actually process the data, let alone do so with an upper limit on latency. [Its not a nuclear reactor or heart pacemaker] In other words, Ocaml is strongly recommended! It will deliver better performance than, for example, a typical C++ solution. IMHO. Its very unlikely the GC will load the system any more intermittently than a C++ memory management system, which, in the long run will be driving the OS virtual memory manager -- and I've seen lots of C++ processes thrash on disk access (typically there are other demands on the disk as well, eg, your data base ..) I suspect the major issue will be whether your long running process fragment memory enough that you must call the compacter -- THAT is likely to 'world stop' for a significant amount of time. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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