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: 103376,8c564a80b820db35 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.129.169 with SMTP id nx9mr20987371pbb.2.1331028518319; Tue, 06 Mar 2012 02:08:38 -0800 (PST) Path: h9ni45426pbe.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Any leap year issues caused by Ada yesterday? Date: Tue, 6 Mar 2012 11:07:46 +0100 Organization: cbb software GmbH 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> 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="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-03-06T11:07:46+01:00 List-Id: On Tue, 06 Mar 2012 09:20:55 +0000, Simon Wright wrote: > "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 know that PowerPC is so much better in that respect than x86. Unfortunately it showed an astonishingly poor performance when we run our initial tests about 2 years ago, so we switched to x86. > 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, Not VxWorks, not Windows (I didn't checked Windows 7, though). Under Windows we use the performance counter and a background thread which synchronizes it with the system clock. This works perfectly well, but requires statistical processing and is too slow for 10kHz cycles we have to run under VxWorks. > (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 Under VxWorks you can read the TSC without assembly, there is a library function for that (pentiumTscGet64). type Timestamp is new Unsigned_64; procedure pentiumTscGet64 (Clock : out Timestamp); pragma Import (C, pentiumTscGet64, "pentiumTscGet64"); should do the work. The actual problem is to get the multiplier, the BIOS time, and keeping the TSC synchronized with the system clock. Funnily Wind River did all that for Pentium IV. But then they were too lazy to support it on more recent x86 processors. The most troublesome thing about VxWorks is that Wind River adds and removes its parts at will. There is no such thing as backward compatibility whatsoever. As for multicore/sleep mode issues, AFAIK Intel fixed that, i.e. the TSC frequency is never changed. I don't know anything about MacOS, but probably they deploy the same lousy schema of getting time from the PIT timer or something like that, so the problems. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de