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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,38d01316d66d8f95
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII
Received: by 10.68.74.201 with SMTP id w9mr14169093pbv.0.1332163303345;
        Mon, 19 Mar 2012 06:21:43 -0700 (PDT)
Path: 
 kz5ni6232pbc.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Ada and linux real time
Date: Mon, 19 Mar 2012 14:20:18 +0100
Organization: cbb software GmbH
Message-ID: <1b51j7r1660r6.ju87xbwmcc2a.dlg@40tude.net>
References: 
 <a2bcd552-9765-487a-a054-6fa48be18b95@y10g2000vbn.googlegroups.com>
 <8kb66jddm0qb.1piup0wfaho1$.dlg@40tude.net>
 <3a01f684-b544-4051-985d-58aab98e832c@v2g2000vbx.googlegroups.com>
 <13z45jd9irz9x.1j2hj7ayxwkyj.dlg@40tude.net>
 <slrnjlg6tv.mv.Eilie@localhost.localdomain> <jja78f$9qm$1@dont-email.me>
 <5777a4dc-67ef-4a35-b929-653a4d498aac@q11g2000vbu.googlegroups.com>
 <jjrkhk$gbf$1@dont-email.me>
 <aba1f8b1-5f02-488d-9a87-9d0a1758dfa7@y10g2000vbn.googlegroups.com>
 <m28vizz9rx.fsf@pushface.org> <m24ntnz0p8.fsf@pushface.org>
 <dead35c2-e25b-46f7-8388-03f3853f2bf3@fk28g2000vbb.googlegroups.com>
 <4f67187d$0$7625$9b4e6d93@newsspool1.arcor-online.net>
 <m2vcm0ycbh.fsf@pushface.org>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org
Mime-Version: 1.0
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: 2012-03-19T14:20:18+01:00
List-Id: <comp.lang.ada>

On Mon, 19 Mar 2012 13:01:22 +0000, Simon Wright wrote:

> I think the point of slos's code is that the delay is supposed to finish
> at Next_Time, but may (if the OS isn't very 'RT') finish later; the code
> measures this.

Though being RT does not imply anything about the precision of such
waiting. Jitter is probably more important, though not essential either.

P.S. 1�s clock resolution looks satisfactory, but rather disappointing. I
expected better from Debian. Can anybody comment on how to fix that?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de