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: 103376,8c564a80b820db35 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.189.197 with SMTP id gk5mr15631134pbc.1.1331025656832; Tue, 06 Mar 2012 01:20:56 -0800 (PST) Path: h9ni45306pbe.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Any leap year issues caused by Ada yesterday? Date: Tue, 06 Mar 2012 09:20:55 +0000 Organization: A noiseless patient Spider Message-ID: References: <4f4f746a$0$6565$9b4e6d93@newsspool3.arcor-online.net> <20608866.730.1330963171058.JavaMail.geo-discussion-forums@ynbq18> <1t8v4akrmapkl.1xwfi9yxtw2ji$.dlg@40tude.net> <18ghv3yeh1a1k$.1bjwdaps59rt3$.dlg@40tude.net> Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="dFCm8HWntFqmDIilBLqEJQ"; logging-data="16184"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Vp3nBE7I7iSXyQNWkFvyasa+kP2NKMCM=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (darwin) Cancel-Lock: sha1:23OtJExldYSPJAkHTvq1BsAhtwA= sha1:qwnP8RWsP7Z6YeRXycT2FCDMdV0= Content-Type: text/plain; charset=us-ascii Date: 2012-03-06T09:20:55+00:00 List-Id: "Dmitry A. Kazakov" writes: > If you set the timer at 1ms rate, you would have 1ms delays. The > problem is that the time stamps would have only 1ms accuracy! For > 10kHz measurements and control we are doing, this is a bit dire. So we > are setting the timer interrupts at 0.01ms (which is our humble > contribution to the "man-made" climate change (:-)) Our (VxWorks) solution was to use the PowerPC timebase register; at each clock tick, store the Ada clock and the current tb; in between, use the tb to interpolate. On the hardware we were using, that gave us 40 ns resolution (a microsecond would have been fine!) I couldn't show you that code even if I still had access, it's proprietary, but there's something at [1]. An Intel equivalent used to work, but (a) most OSs give microsecond resolution anyway, (b) it certainly doesn't work on Mac OS X with dual cores where the core is slowed right down if it has nothing to do! (my interpretation of the observed behaviour). [1] http://booch95.svn.sourceforge.net/viewvc/booch95/trunk/src/bc-support-high_resolution_time-clock.adb-ppc32?revision=1415&view=markup