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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border1.nntp.dca1.giganews.com!Xl.tags.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 24 Nov 2014 11:24:07 -0600 From: Dennis Lee Bieber Newsgroups: comp.lang.ada Subject: Re: how to analyze clock drift Date: Mon, 24 Nov 2014 12:24:15 -0500 Organization: IISS Elusive Unicorn Message-ID: References: <188uppnlnvqgq$.1kjz3jnhjxqji.dlg@40tude.net> <87fvdd38qi.fsf@debian.uxu> <87a93l35dm.fsf@debian.uxu> <9t7t6al8bmifd9krh6koiegttgsvcovadg@4ax.com> <87d28h1cj9.fsf@debian.uxu> <3apu6ap126abi6oalch9vpre20hjij2uon@4ax.com> <87k32oi7r8.fsf@debian.uxu> <98h17atrhtl9kitthjf8ukt1f7rk1ribvc@4ax.com> <8761e54qt2.fsf@debian.uxu> X-Newsreader: Forte Agent 6.00/32.1186 X-No-Archive: YES MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 108.79.223.64 X-Trace: sv3-YQzKeE8nTd/ZyVyPIrCfUir316uRZLHBR7huxeAOCk4nsEwqsJRNb/Dv0VE9y96KT93rTu1Fr8cK5vA!HB6NJGIvfGduuDKp5JUltPowN73Rdpru8zlM1CPiP6uDzHeR9mij53qMgiEpomBdt5Kbmz2rL/VH!igF/TdoPyJpxnPHijAWPOglp0oM= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3484 X-Received-Bytes: 3658 X-Received-Body-CRC: 3467993958 Xref: news.eternal-september.org comp.lang.ada:23695 Date: 2014-11-24T12:24:15-05:00 List-Id: On Mon, 24 Nov 2014 09:44:39 +0100, "Dmitry A. Kazakov" declaimed the following: >Setting THREAD_PRIORITY_TIME_CRITICAL blocks practically everything (except >for drivers). > >However I doubt that background processes or services are the problem when >waiting for 10 or 5ms > Many moons ago I had a task using a GFE W98 (!) laptop [needed to be W9x to allow direct access to the parallel port]. Wasn't a timer situation -- it was more a busy wait since the main timing control was obtained from an external (1KHz as I recall) clock to a signal pin on the parallel port. The task required writing 6-bits on each clock transition (I forget if L->H, or H->L) -- the 6-bits representing three RS-422-style balanced data lines... Even with the priority values (as I recall, there were two that needed to be set, a process class priority and a priority within the class) at maximum, Windows still tended to trash the data transfer every 250mSec or so with some overhead operation. Fortunately, that laptop never did go operational (the overall assignment was to use the laptop as a mini-command formatter to transfer /red/ GPS decryption keys to a GPS receiver in the testing lab without causing the entire lab to go limited-access classified -- instead the laptop would be locked in a safe when not loading keys). By the time the key loading was really needed, the CONOPS changed to /black/ keys which could go through the normal lab equipment. If given that assignment today -- I'd recommend dropping the parallel port requirement and use something like an Arduino (a BASIC Stamp 2p has enough memory and pins to support it, just not the speed)... Let the laptop transfer the command string to the Arduino, which would then handle the clock synch and output. Definitely easier to communicate with -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/