From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,aba1514f4a1fc450 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.85.136 with SMTP id h8mr1815568paz.46.1345990829895; Sun, 26 Aug 2012 07:20:29 -0700 (PDT) MIME-Version: 1.0 Path: t10ni62970945pbh.0!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.snarked.org!newsfeed.news.ucla.edu!ihnp4.UCSD.Edu!nntp.ucr.edu!solaris.cc.vt.edu!news.vt.edu!news.glorb.com!news.mixmin.net!news.albasani.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.arch,comp.lang.ada Subject: Re: Have the Itanium critics all been proven wrong? Date: Wed, 22 Aug 2012 17:30:22 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <5021874F.1747D0BF@sonic.net> <46f19bfc-930e-4f06-b5a6-c60f39cfda0c@p14g2000yqk.googlegroups.com> <077b12f6-1196-4b5c-bbdb-04291b1ae616@q22g2000vbx.googlegroups.com> <589825d2-d998-456a-9c37-c8ae13e1e7bc@e29g2000vbm.googlegroups.com> <4c83f0f4-30e2-44bd-8b73-ada05de9322b@q22g2000vbx.googlegroups.com> <7399f70e-ffca-4517-8b8d-532d09539a85@d9g2000vbf.googlegroups.com> <00dcc463-e9d2-490d-93bc-4ec2084522db@l9g2000vbj.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1345674627 17010 69.95.181.76 (22 Aug 2012 22:30:27 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 22 Aug 2012 22:30:27 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Received-Bytes: 4100 Date: 2012-08-22T17:30:22-05:00 List-Id: "Michael S" wrote in message news:00dcc463-e9d2-490d-93bc-4ec2084522db@l9g2000vbj.googlegroups.com... On Aug 22, 3:43 pm, Michael S wrote: > On Aug 22, 1:54 pm, Niklas Holsti wrote: ... > I'd say, the biggest difference between RSESs and RBaRCAPs is that in > RSES maximal load as well as minimal available resources are know up > front. RBaRCAP, on the other hand, should, at least to a certain > degree, handle increased loads and decreased resources by gracefully > degrading the quality of service (i.e. typically response time). It's > also desirable for RBaRCAP to supply better than normal quality of > service when the loads are low or resources are high. > Restating the same from slightly different angle, RSES are [hard or > soft] real-time while RBaRCAP are ether non-real-time (if you believe > that true non-real-time still exists) or, more realistically, > extremely soft real time. The web server that runs the Ada search engine (providing search for various Ada standards and other documents) and hosting the Ada-auth.org website is such an application; it runs 24x7 and it is 100% Ada. I wouldn't call it "really big" though (I think it is around 120Kloc). And it does use Unchecked_Deallocation, I thought that might be a problem in a long running application, but I've never seen any problem with fragmentation or the like even when it is up for several months. (It tends to get restarted every couple of months to install the never-ending stream of patches from Microsoft, so I don't have any real data on what would happen if it ran for a year or more - although I would be surprised if it changed much. I've also got a spam filter/mail exchanger program that also runs 24x7, is about the same size, and has similar characteristics. My understanding is that these are small systems compared to those used by our customers, but I have no direct experience with those systems. Randy.